Auxiliary uplink in wireless systems

Abstract

Supplemental uplinks (SULs) may be used in wireless systems. Cell compatibility criteria may be provided for cells configured with SULs. [Solution] A wireless transmit / receive unit (WTRU) may receive paging along with an indication of a carrier (e.g., SUL or regular uplink (RUL)) to initiate some or all of the initial access. A WTRU that may be performing response-driven paging may provide (e.g., explicit) beam information for beamforming paging messages on a non-beamforming SUL. A handover (HO) procedure may be provided to a WTRU having a configured SUL. A WTRU may (e.g., autonomously) switch to a different (e.g., configured) uplink (e.g., conditional switch) when one or more conditions may be met.

Description

[Technical Field]

[0001] This disclosure relates to auxiliary uplinks in wireless systems. [Background technology]

[0002] Cross-reference of related applications This application claims the interests of Provisional U.S. Patent Application No. 62 / 585,878, filed November 14, 2017, U.S. Patent Application No. 62 / 615,255, filed January 9, 2018, and U.S. Patent Application No. 62 / 629,901, filed February 13, 2018, the entirety of which is incorporated herein by reference.

[0003] Mobile communications using wireless communication continue to develop. The fifth generation is sometimes called 5G. Previous (legacy) generations of mobile communications could be, for example, the fourth generation (4G) Long-Term Evolution (LTE). [Overview of the project]

[0004] Systems, methods, and means for auxiliary uplinks (SULs) in wireless systems are disclosed. For cells configured with SULs, cell compatibility criteria may be provided. A WTRU may receive paging with indication of the carrier (e.g., SUL or regular uplink (RUL)) on which some or all of the initial access should be initiated. A wireless transceiver unit (WTRU) that may be performing response-driven paging may provide beam information (e.g., explicit) about beamforming of paging messages on a non-beamformed SUL. Handover (HO) procedures (e.g., carrier selection, configuration handling, HO failure) may be provided to a WTRU having a configured SUL. A WTRU may request a change in a configured UL. A WTRU may perform a switch to a different (e.g., configured) uplink (e.g., autonomously) when one or more conditions may be met (e.g., conditional switching). A semi-persistent scheduling (SPS) resource / configuration may be relocated from a first UL to a second UL. In the presence of a SUL, duplication and UL route selection may be provided for Radio Resource Control (RRC) messages. A WTRU may trigger or not trigger a Radio Link Fault (RLF) relationship, for example, based on whether conditions for the RLF relationship have occurred on the SUL / RUL and based on the SUL / RUL configuration. Conditions may be set for pausing / resetting RLF relationship counters / timers during switching between RUL / SUL. A WTRU may inform the master node (MN) of the RUL / SUL configuration, for example, during secondary cell group (SCG) failure information reporting. For partial SCG failures that can be triggered by an SCG RLF on the RUL, procedures may be implemented (for example, with corresponding WTRU behavior). A WTRU may select the UL carrier (e.g., SUL / RUL) on which to initiate re-establishment. In the presence of a SUL / RUL, procedures may be provided for UL selection of system information (SI) requests.

[0005] The WTRU receives a handover (HO) command and may select an uplink (UL) carrier for the HO based on the HO command. For example, if the HO command includes an explicit designation for one UL carrier for the HO, the WTRU may select the UL carrier for the HO based on whether the random access channel (RACH) resource is provided to an auxiliary uplink (SUL) or a regular uplink (RUL) in the HO command. If the HO command includes configurations for both SUL and RUL in the HO command, the WTRU may select the UL carrier for the HO based on whether the downlink reference signal received power (DL-RSRP) of the SUL is below a threshold. For example, if the DL-RSRP of the SUL is below the threshold, the SUL is selected as the UL carrier for the HO, and if the DL-RSRP of the SUL is above the threshold, the RUL is selected as the UL carrier for the HO.

[0006] A wireless transceiver unit (WTRU) may use different cell compatibility criteria depending on whether the cell is configured using SUL supported by the WTRU. For example, the WTRU may determine the cell's compatibility. If the cell is configured using SUL and the WTRU supports SUL communication for the cell's frequency (e.g., SUL frequency), the WTRU may determine the cell's compatibility using a first cell compatibility criterion. If the cell is not configured using SUL, or if the WTRU does not support SUL communication for the cell's frequency, the WTRU may determine the cell's compatibility using a second cell compatibility criterion. The WTRU may then select a cell based on the determined cell compatibility and camp on to the selected cell.

[0007] The first cell compatibility criterion may include (e.g., may be available) a cell-specific SUL offset. The second cell compatibility criterion may include (e.g., may be available) a cell-specific non-SUL offset that is different from the SUL offset. The WTRU may receive SUL offsets and / or non-SUL offsets from the network. The WTRU may receive system information from the cell, determine that the system information includes SUL configuration information, and, based on the receipt of the SUL configuration information, determine that the cell is configured with SUL (e.g., or not configured with SUL).

[0008] The WTRU may receive a System Information Block (SIB) from a cell containing information relating to a second cell and determine the suitability of the second cell based on the SIB. For example, if the second cell is configured with SUL and the WTRU supports SUL communication, the WTRU may determine the suitability of the second cell using a third cell suitability criterion (including, for example, the SUL offset). However, if the second cell is not configured with SUL or the WTRU does not support SUL communication, the WTRU may determine the suitability of the second cell using a fourth cell suitability criterion (including, for example, the non-SUL offset). The SIB may indicate whether the second cell supports SUL communication. The SIB may include a display of a neighboring cell list with cell identification (ID) for SUL-supporting cells, and / or a display of the SUL frequency for SUL-supporting cells. [Brief explanation of the drawing]

[0009] The same reference number in the diagram refers to the same element.

[0010] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown in Figure 1A according to an embodiment. [Figure 1C]FIG. 0 is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that can be used within the communication system shown in FIG. 1A according to an embodiment. [Figure 1D] FIG. 3 is a system diagram showing a further exemplary RAN and a further exemplary CN that can be used within the communication system shown in FIG. 1A according to an embodiment. [Figure 2] FIG. 6 is a diagram of an exemplary coverage map of a cell (e.g., gNB). [Figure 3] FIG. 9 is a diagram of an exemplary coverage map showing two cells. [Figure 4] FIG. 12 is a flowchart of an exemplary cell selection / reselection procedure that can be performed by a WTRU. DETAILED DESCRIPTION OF THE INVENTION

[0011] Next, a detailed description of exemplary embodiments will be described with reference to various figures. It should be noted that this description provides detailed examples of possible implementations, but these details are intended to be exemplary and are not intended to limit the scope of the present application in any way.

[0012] Figure 1A shows an exemplary communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as code division multiple access (CDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), quadrature 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, and filtered bank multicarrier (FBMC).

[0013] As shown in Figure 1A, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments intend any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d, sometimes referred to as both "stations" and / or "STAs," may be configured to send and receive wireless signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), consumer electronics devices, and devices operating on commercial and / or industrial wireless networks. Any of WTRU102a, 102b, 102c, and 102d may be interchangeably referred to as UEs.

[0014] The communication system 100 may also include base stations 114a and / or base stations 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, the Internet 110, and / or other networks 112. For example, base stations 114a and 114b may be base transceiver stations (BTS), node B, enode B, home node B, home enode B, gNB, NR node B, site controller, access point (AP), wireless router, etc. Although base stations 114a and 114b are illustrated as single elements, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

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

[0016] Base stations 114a, 114b may communicate with one or more 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).

[0017] More specifically, as described above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may establish air interfaces 115 / 116 / 117 using broadband CDMA (WCDMA). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

[0019] In the embodiment, base stations 114a and WTRUs 102a, 102b, and 102c may implement radio technologies such as NR radio access, which can establish an air interface 116 using New Radio (NR).

[0020] In the embodiment, base station 114a and WTRU 102a, 102b, 102c may implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c may implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 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., eNB and gNB).

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

[0022] The base station 114b in Figure 1A may be, for example, a wireless router, home node B, home e-node B, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in localized areas such as businesses, homes, vehicles, campuses, industrial facilities, aerial corridors (for use by drones, for example), roads, etc. In one embodiment, the base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In another embodiment, the base station 114b and WTRU 102c, 102d may implement radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and WTRU 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. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b may not need to access the internet 110 via CN 106 / 115.

[0023] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various Quality of Service (QoS) requirements, including different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location-based services, prepaid calling, internet connectivity, video distribution, and / or implement high-level security functions such as user authentication. Although not shown in Figure 1A, it should be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same or different RATs as RAN104 / 113. For example, in addition to being connected to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 may also communicate with other RANs (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0024] CN106 / 115 may also act as a gateway for WTRU102a, 102b, 102c, and 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing simple old-fashioned telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) in the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may employ the same RAT as RAN104 / 113 or a different RAT.

[0025] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with base station 114a which may employ cellular-based radio technology and base station 114b which may employ IEEE 802 radio technology.

[0026] Figure 1B is a system diagram showing an exemplary WTRU 102. As shown in Figure 1B, the WTRU 102 may include, in particular, 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 supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripherals 138. It will be understood that the WTRU 102 may include any partial combination of the above elements while remaining conforming to the embodiment.

[0027] The processor 118 may be a general-purpose processor, a dedicated processor, a conventional processor, a digital signal processor (DSP), multiple microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, 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 functions that enable the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to a transceiver 120 that can be coupled to the transmit / receive element 122. Although Figure 1B shows the processor 118 and transceiver 120 as separate components, it will be understood that the processor 118 and transceiver 120 may be integrated with each other in an electronic package or chip.

[0028] The transmitting / receiving element 122 may be configured to transmit signals to or receive signals from a base station (e.g., base station 114a) via the air interface 116. For example, in one embodiment, the transmitting / receiving element 122 may be an antenna configured to transmit and / or receive RF signals. In another embodiment, the transmitting / receiving 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 transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It will be understood that the transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0029] Although the transmit / receive element 122 is illustrated as a single element in Figure 1B, 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) to transmit and receive wireless signals via the air interface 116.

[0030] The transceiver 120 may be configured to modulate the signal to be transmitted by the transmitting / receiving element 122 and to demodulate the signal received by the transmitting / receiving element 122. As described above, the WTRU 102 may have multimode capability. Therefore, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs, such as NR and IEEE 802.11.

[0031] The processor 118 of the WTRU102 may be coupled to 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) and may receive user input data from them. 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 any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. 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. Removable memory 132 may include a subscriber identification module (SIM) card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access information from memory not physically located on the WTRU 102, such as on a server or home computer (not shown), and store data therein.

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

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

[0034] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functions and / or wired or wireless connectivity. For example, 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 modulation (FM) radio unit, a digital music player, a media player, a video game player module, an internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, and the like. 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 biosensor, and / or a humidity sensor.

[0035] WTRU102 may include a full-duplex radio in which the transmission and reception of some or all of a signal (for example, related to a particular subframe for both the UL (e.g., for transmission) and the downlink (e.g., for reception) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference either through hardware (e.g., chokes) or through signal processing via a processor (e.g., via a separate processor (not shown) or processor 118). In embodiments, WTRU102 may include a half-duplex radio in which the transmission and reception of some or all of a signal (for example, related to a particular subframe for either the UL (e.g., for transmission) or the downlink (e.g., for reception) may be concurrent and / or simultaneous.

[0036] Figure 1C is a system diagram showing RAN104 and CN106 according to an embodiment. As described above, RAN104 may employ E-UTRA radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0037] RAN104 may include enodes B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of enodes B while remaining in accordance with the embodiment. Each enode B160a, 160b, and 160c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, enodes B160a, 160b, and 160c may implement MIMO technology. In this way, for example, enode B160a may use multiple antennas to transmit and / or receive wireless signals from WTRU102a.

[0038] Each of the e-nodes B160a, 160b, and 160c may be associated with a specific cell (not shown) and may be configured to handle wireless resource management decisions, handover decisions, user scheduling in UL and / or DL, etc. As shown in Figure 1C, the e-nodes B160a, 160b, and 160c may communicate with each other via the X2 interface.

[0039] The CN106 shown in Figure 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 above elements is illustrated as part of CN106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0040] The MME162 may be connected to each of the e-nodes B162a, 162b, and 162c in RAN104 via the S1 interface and can function as a control node. For example, the MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. The MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0041] The SGW164 can be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. The SGW164 can generally route and forward user data packets to and from WTRU102a, 102b, and 102c. The SGW164 can perform other functions, such as anchoring the user plane during e-node B handovers, triggering paging when DL data is available for WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0042] SGW164 may be connected to PGW166, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 in order to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0043] CN106 may facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional landline communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) acting as an interface between CN106 and PSTN108. In addition, CN106 may provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0044] Although WTRUs are described as wireless terminals in Figures 1A to 1D, in some representative embodiments, such terminals are intended to be able to use a wired communication interface with a communication network (for example, temporarily or permanently).

[0045] In a typical embodiment, the other network 112 may be a WLAN.

[0046] In Infrastructure Basic Service Set (BSS) mode, a WLAN may have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP may have access to or interfaces with a Distribution System (DS) or another type of wired / wireless network that carries traffic in and / or from the BSS. Traffic originating from outside the BSS to an STA may arrive via an AP and be delivered to the STA. Traffic originating from an STA to a destination outside the BSS may be sent to the AP to which it should be delivered to its respective destination. Traffic between STAs within the BSS may be sent via an AP; for example, a source STA may send traffic to an AP, and the AP may deliver the 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 a source STA and a destination STA (for example, directly between them) using a Direct Link Setup (DLS). In some typical embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunneled DLS (TDLS). A WLAN using Independent BSS (IBSS) mode may not have access points (APs), and STAs (e.g., all STAs) that are in or using IBSS can communicate directly with each other. The IBSS communication mode is sometimes referred to herein as the “ad-hoc” communication mode.

[0047] When using the 802.11ac infrastructure operating mode or a similar operating mode, an AP may transmit beacons on a fixed channel, such as the primary channel. The primary channel may be of a fixed width (e.g., a 20 MHz bandwidth) or a dynamically set width via signaling. The primary channel may be the operating channel of the BSS and may be used by an STA to establish a connection with the AP. In some typical embodiments, for example in an 802.11 system, Carrier Sense Multiple Access / Collision Avoidance (CSMA / CA) may be implemented. For CSMA / CA, an STA, including the AP (e.g., any STA), may sense the primary channel. If a particular STA senses / detects the primary channel and / or determines that it is busy, that particular STA may backoff. In a given BSS, one STA (e.g., just one station) may transmit at a given time.

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

[0049] Ultra-high throughput (VHT) STAs may support 20MHz, 40MHz, 80MHz, and / or 160MHz wide channels. 40MHz and / or 80MHz channels may be formed by combining consecutive 20MHz channels. 160MHz channels may be formed by combining eight consecutive 20MHz channels or two discontinuous 80MHz channels, sometimes referred to as an 80+80 configuration. In an 80+80 configuration, the data after channel coding may pass through a segment parser, which may split the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing may be performed separately on each stream. The streams may be mapped onto two 80MHz channels, and the data may be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation described above for the 80+80 configuration may be reversed, and the combined data may be sent to media access control (MAC).

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

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

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

[0053] Figure 1D is a system diagram showing RAN113 and CN115 according to an embodiment. As described above, RAN113 may employ NR radio technology to communicate with WTRU102a, 102b, and 102c via air interface 116. RAN113 may also communicate with CN115.

[0054] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while remaining conforming to the embodiment. Each of the gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, the gNB180a, 180b, and 180c may implement MIMO technology. For example, the gNB180a and 180b may utilize beamforming to transmit signals to and / or receive signals from the gNB180a, 180b, and 180c. In this way, for example, the gNB180a may use multiple antennas to transmit and / or receive wireless signals from the WTRU102a. In embodiments, gNB180a, 180b, and 180c may implement carrier aggregation techniques. For example, gNB180a may transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, while the remaining component carriers may be on the licensed spectrum. In embodiments, gNB180a, 180b, and 180c may implement coordinated multipoint (CoMP) techniques. For example, WTRU102a may receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0055] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions related to scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different parts of the wireless transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTI) of varying or scalable lengths (including, for example, a varying number of OFDM symbols and / or varying durations of absolute time).

[0056] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (such as e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more of gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c may communicate with / connect to gNB180a, 180b, and 180c while simultaneously communicating with / connecting to other RANs such as enodes B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c may implement DC principles to communicate substantially simultaneously with one or more gNB180a, 180b, and 180c and one or more enodes B160a, 160b, and 160c. In a non-standalone configuration, enodes B160a, 160b, and 160c may act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c may provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0058] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and possibly a Data Network (DN)185a, 185b. Although each of the above elements is illustrated as part of the CN115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0059] AMF182a and 182b may be connected to one or more of gNB180a, 180b, and 180c in RAN113 via the N2 interface and can act as control nodes. For example, AMF182a and 182b may be responsible for authenticating users of WTRU102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different requirements), selecting specific SMF183a and 183b, managing registration areas, terminating NAS signaling, and mobility management. Network slicing may be used by AMF182a and 182b to customize CN support for WTRU102a, 102b, and 102c based on the type of services utilized by WTRU102a, 102b, and 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-high reliability low latency (URLLC) access, services relying on extended capacity mobile broadband (eMBB) access, and services for machine-type communications (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) employing other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0060] SMF183a and 183b can be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b can also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure traffic routing through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and allocating WTRU / UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0061] UPF184a and 184b may be connected via the N3 interface to one or more of the gNB180a, 180b, and 180c in RAN113, which may provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices. UPF184 and 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, and providing mobility anchoring.

[0062] CN115 may facilitate communication with other networks. For example, CN115 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. In addition, CN115 may provide WTRU102a,102b,102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a,102b,102c may be connected to the local data network (DN) 185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and DN185a,185b.

[0063] In view of Figures 1A to 1D and their corresponding descriptions, one or more, or all, of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to ab, UPF184a to b, SMF183a to b, DN185a to b, and / or any other devices described herein may be implemented by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, an emulation device may be used to test other devices and / or to simulate network and / or WTRU functions.

[0064] Emulation devices may be designed to implement one or more tests of other devices in a laboratory environment and / or a carrier network environment. For example, one or more emulation devices may perform one or more, or all, functions while being fully or partially implemented and / or deployed as part of a communication network to test other devices within a wired and / or wireless communication network. One or more emulation devices may perform one or more, or all, functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Emulation devices may be directly coupled to another device for test purposes and / or tests may be performed using over-the-air wireless communications.

[0065] One or more emulation devices may perform one or more functions, including all of the above, without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test laboratory and / or a wired and / or wireless communication network that is not deployed (e.g., for testing purposes) to implement testing of one or more components. 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 device to transmit and / or receive data.

[0066] The examples provided herein do not limit the applicability of this subject matter to other wireless technologies that use the same or different principles, for example, which may be applicable.

[0067] The term "network" may refer to one or more gNBs that may be associated (for example, successively) with one or more transmit / receive points (TRPs) or other nodes in a radio access network (RAN).

[0068] A cell may be configured using an auxiliary uplink (SUL) (for example in NR). The SUL can extend the coverage of a WTRU that may be operating at higher frequencies, for example, by switching the UL to a lower bandwidth when the WTRU may be far from the gNB. The SUL can be modeled (for example in NR) as a cell with DL carriers that may be associated with multiple (e.g., two) separate UL carriers. For example, the DL carriers may be associated with a regular UL (RUL) (for example, in a higher frequency band where the DL carrier may be located) and with the SUL (for example, in a lower frequency band than the frequency band of the RUL).

[0069] SUL can be configured for PCell (for example in NR standalone mode) and PSCell (for example in NR-NR DC, or in dual connectivity between LTE and NR, sometimes called NSA mode or EN-DC).

[0070] A WTRU may perform initial access to a cell using, for example, a RUL or SUL. A SUL configuration may be broadcast by the cell during the minimum SI. A WTRU may choose SUL for initial access, for example, when the DL quality of a serving cell may fall below a threshold (for example, only then).

[0071] When a WTRU is in an RRC connection, multiple (e.g., three) operating modes may be possible for a SUL. The RRC may configure the WTRU with multiple (e.g., two) ULs (e.g., in a first operating mode), such as a full UL configuration and a sounding reference signal (SRS) configuration. The WTRU may use a fully configured UL configuration (e.g., for full control and data transmission on the uplink) (e.g., in this operating mode), but may transmit an SRS on another (e.g., an incompletely configured) uplink. RRC reconfiguration may be used (e.g., to provide a full UL configuration to different carriers) to switch between UL data between different ULs. The RRC may configure multiple ULs (e.g., fully configured ULs), such as two fully configured ULs (e.g., two fully configured ULs), (e.g., in a second operating mode). Signaling such as MAC CE or DCI may be defined to enable the WTRU to switch between UL configurations. RRC can constitute multiple (e.g., two) ULs, which may be used (e.g., both) when, for example, a PUSCH transmission for a single serving cell may not be performed simultaneously for multiple ULs.

[0072] SUL can be supported in RRC. In carrier aggregation, UL carriers (e.g., each UL carrier) can be related to (e.g., a single) DL carrier in the same bandwidth and thus scheduled.

[0073] The UL carriers that may be used in the RRC procedure may be related to (for example, each) RRC state. The rules may be related to initial access to cells that have SUL. The selection of UL carriers for (for example, each) RRC procedure may depend on factors that are greater than or different from DL quality.

[0074] SULs can exist in different frequency bands than DL carriers. A cell's UL carrier (for example, in LTE) can exist on the same frequency as the DL carrier. For example, when implementing response-driven paging, a paging indicator response performed on an SUL may not be used by the network (NW) to select a DL beam for transmitting the paging record.

[0075] WTRU may have different coverage depending on the use of RUL or SUL. One or more procedures (e.g., RLF, SCG failure, re-establishment, etc.) may take into account the UL carrier used for one or more procedures to match their intended purpose.

[0076] One or more procedures may limit the use of SUL by WTRU. For example, even when (e.g., all) DL carriers in a high-frequency band can be constructed using SUL, it may be preferable to reduce the number of carriers that should be constructed as SUL (for example, if they could also be the cell's normal UL carriers at lower frequencies).

[0077] A WTRU may be configured to implement one or more criteria based on cell selection and / or reselection in an NR system using SUL. In cell selection and / or cell reselection, existing criteria in E-UTRAN may be calculated taking into account DL RSRP and RSRQ with offset compensation for higher priority cells. The transmit power of the WTRU may be taken into account using the parameter Pcompensation. The cell selection criterion S in normal coverage in E-UTRAN is Srxlev>0 and Squal>0 may be satisfied when Srxlev=Q rxlevmeas -(Q rxlevmin +Q rxlevminoffset )-Pcompensation-Qoffset temp Squal=Q qualmeas -(Q qualmin +Q qualminoffset )-Qoffset temp Pcompensation=max(P EMAX1 -P PowerClass 、0) (dB) is.

[0078] A WTRU's Tx power (PPowerClass) lower than the allowed value (PEMAX1) in a cell may result in a larger PCompensation value (e.g., making it more difficult to select the cell). Some correspondence between UL transmission and DL transmission may be assumed in an LTE band. However, in mmWave, UL transmission may be affected (e.g., strongly affected) by the propagation environment. In such scenarios, the above equations may be insufficient for cell selection and / or reselection.

[0079] FIG. 2 is a diagram of an exemplary coverage map 200 of a cell 202 (e.g., a gNB). At high frequencies (e.g., high New Radio (NR) frequencies), the UL coverage of cell 202 may be significantly smaller than the DL coverage of cell 202. Cell 202 may include a supplementary UL (SUL), which may be at a lower frequency than, for example, the regular UL (RUL) and downlink (DL) of cell 202. The RUL and SUL may be paired with each DL of a cell (e.g., a SCell). The WTRU 204 may camp on the SUL when the RSRP < SUL_threshold (e.g., when the RSRP of the RUL is < SUL_threshold). The network may deploy the SUL unevenly in the area (e.g., some cells may include the SUL while other cells may not). Support for the SUL by the WTRU 204 may be defined for each combination of bands (e.g., for each frequency). The WTRU 204 may not support the SUL configured for a particular cell (e.g., the WTRU 204 may not support the SUL for the frequency of the SUL of a cell). If the WTRU 204 uses only DL measurements, the WTRU 204 may camp in a cell with poor uplink coverage, which may lead to unnecessary handovers or re-establishments during connection. The examples provided herein may be used, for example, to ensure that a WTRU camps on a cell having the best combination of downlink and uplink coverage in an environment where SUL / non-SUL support is mixed.

[0080] Figure 3 is a diagram of an exemplary coverage map 300 showing two cells 302 and 304. Cell 302 may not support SUL (for example, as indicated by the area of ​​no-UL coverage 308), while cell 304 may support SUL. WTRU 306 may be located close to the boundary between cell 302 and the SUL coverage area of ​​cell 304. Thresh_1 may indicate a threshold (e.g., a cell quality threshold such as RSRP) that WTRU 306 uses when determining whether to remain camped within cell 302 or to re-select for the SUL of cell 304. The SUL threshold may indicate a threshold (e.g., a cell quality threshold such as RSRP) that WTRU 306 uses when determining whether to communicate with cell 304 over RUL or to switch to communicating via the SUL of cell 304.

[0081] Figure 4 is a flowchart of an exemplary cell selection / reselection procedure 400 that may be performed by a WTRU. A WTRU that supports SUL may use a modified cell selection and / or cell reselection procedure to prioritize cells that utilize SUL in a bandwidth combination supported by the WTRU over cells that do not support SUL. For example, for cells that utilize SUL in a bandwidth combination supported by the WTRU, the WTRU may receive bias / offset information for one or more of the following: S-criterion evaluation (e.g., SUL cell suitability offset), neighbor cell measurement triggering threshold (e.g., SmeasThres), neighbor cell reselection ranking criterion (e.g., Rn), and / or serving cell reselection ranking criterion (Rs). The bias / offset information may be provided in the system information. The bias / offset information may be used by (e.g., only by) a WTRU that supports SUL in a bandwidth combination (e.g., transparent to the network for idle-mode WTRUs). The bias / offset information may be used to prefer SUL cells during cell selection and reselection.

[0082] For example, in 402, 404, 410, and 412, the WTRU may determine selection or reselection parameters based on the WTRU's serving DL cell quality (e.g., RSRP) and / or SUL support (e.g., on SUL frequencies). In 406, 408, 414, 416, and 418, the WTRU may use, for example, the values ​​determined in 402, 404, 410, and / or 412 to perform evaluation and / or selection / reselection procedures. In 404-408, the WTRU may measure other cells to determine whether ranking and reselection should be triggered. In 412-418, the WTRU may perform cell ranking and reselection decisions. In 414-416, neighbor cells to be considered for reselection may depend further on the same conditions as in 406-408.

[0083] The WTRU may determine whether one or more cells (e.g., a camped cell, a target to camp, a neighbor cell, etc.) utilize SUL. For example, in 402, the WTRU may determine whether a camped cell supports SUL, while in 410, the WTRU may determine whether one or more neighbor and / or potential reselection cells support SUL. In 404, the WTRU may determine (e.g., based on system information and WTRU capabilities) whether a camped cell supports SUL (e.g., a combination of bandwidths). If so, the WTRU may use the SUL eigenvalues ​​of S and SmeasThres (e.g., S(SUL), SmeasThres(SUL)) when performing a reselection analysis. Otherwise, the WTRU may use the RUL eigenvalues ​​of S and SmeasThres (e.g., S(RUL), SmeasThres(RUL)) when performing a reselection analysis.

[0084] Similarly, when determining SUL support on the neighbor and target cells at 410, the WTRU may determine whether the WTRU supports SUL on the neighbor cell and / or whether DL_RSRP < Thresh_1. If the WTRU supports SUL on the cell and DL_RSRP < Thresh_1, the WTRU may use offset values (e.g., Rn’ = Rn + offset and Rs’ = Rs + offset) when performing, for example, evaluation and / or selection / reselection analysis. If the WTRU supports SUL on the cell and / or DL_RSRP ≧ Thresh_1, the WTRU may use Rn’ = Rn and Rs’ = Rs when performing, for example, evaluation and / or selection / reselection analysis. As described above, at 406, 408, 414, 416, and 418, the WTRU may perform evaluation and / or selection / reselection procedures using, for example, the values determined in 402, 404, 410, and / or 412.

[0085] Examples of idle / inactive state procedures for the use of SUL are provided herein. For example, a cell compatibility criterion may take into account the presence of SUL / RUL configurations. A cell compatibility criterion may be applied to one or more (e.g., all) procedures (e.g., camp) in which cell compatibility may be utilized. A cell compatibility criterion may depend on whether a cell can be configured using SUL and may utilize one or more of the cell quality thresholds, offsets, or criteria (e.g., Squal or similar) for a suitable cell. For example, the thresholds, offsets, and / or criteria for SUL may differ from those for RUL. A WTRU may receive offset or correction parameters that can be used to determine the cell compatibility criterion, depending, for example, whether a cell can be configured using SUL and / or whether the WTRU supports SUL features. Alternatively or additionally, a WTRU may utilize multiple (e.g., two) different cell compatibility criterion calculations. For example, a WTRU may select a first calculation to determine the compatibility of a cell that transmits SUL configuration information in its system information. When the WTRU determines the compliance criteria for a cell that does not transmit a SUL configuration in its system information, or when, for example, the WTRU may not support SUL features, it may choose a second compliance criterion calculation.

[0086] Idle cell selection may be implemented with SUL / RUL in mind. For example, a WTRU may consider the quality of UL transmissions in a cell in its cell selection criteria. For instance, a WTRU may distinguish cells configured with SUL for suitability assessment. A WTRU may determine suitability assessment based on one or more of the following: For example, such distinction / assessment may depend on the frequency carriers of RUL and paired DL, take into account the configuration of SUL (e.g., where applicable), be captured in UL Pcompensation used in the evaluation of the cell selection criteria, and be evaluated through a new cell selection criterion that takes into account the cell propagation characteristics (e.g., and the configuration of SUL, where applicable), as well as / or take into account the associated cell selection parameters to favor or otherwise prefer one of the two configurations (e.g., RUL vs. SUL).

[0087] In the example, additional cell selection-reselection criteria may be introduced to assess the impact of WTRU uplink transmission propagation and the need to select cells with configured SULs (for example, where applicable). For example, any combination of the following three conditions may be used to select a given cell. Srxlev>0, Squal>0, and / or Stxlev>0 however, Stxlev=Q rxlevmeas -Q rxlevthreshold +Q SUL-offset , Q rxlevmeas This is the measured cell RX level value (RSRP), Q rxlevthreshold This is the configured RSRP threshold received by the WTRU in RMSI. Q SUL-offset This is a signaled Q. rxlevthreshold It is an offset relative to (for example, Q) SUL-offset (This can be used in Stxlev evaluation to adjust its value when SUL and associated power corrections are configured in a cell.) When SUL is not configured, Q SUL-offset =0 That is the case.

[0088] Additional cell selection-reselection criteria may be used when selecting cells with configured SULs (for example, if applicable). The cell's Pcompensation value takes the SUL configuration into account. In mmWave, even if the maximum transmit power of a WTRU is equal to the maximum allowable power in the cell, the UL coverage may not be sufficient for the WTRU to reach its serving transmit point. In the Pcompensation calculation, a frequency offset Q is used to capture the propagation conditions of the WTRU in the UL at higher frequencies, when the SUL is configured and when it is not. freq-offset This could be introduced. Pcompensated = max(P EMAX1 -P PowerClass +Q freq-offset ,0) (dB) however, P EMAX1 This is the maximum TX power level (dBm) that a WTRU can use when transmitting on the uplink in a cell. P PowerClass This is the maximum RF output power (dBm) of the WTRU by WTRU power class. Q freq-offset As a result, the signaled P was taken into consideration in the Pcompensation assessment. PowerClass This is the offset relative to

[0089] Q freq-offset The value of can be a function of the cell frequency carrier and the configuration of the SUL (e.g., no or no configuration). This makes cells with configured SULs more likely to be selected by the WTRU, while it can be made (e.g., intentionally) more difficult / less likely for the WTRU to select cells with poor estimated UL coverage and no configured SULs.

[0090] In the example, the cell selection criteria for SUL can be based on the following: Srxlev>0, Squal>0, and / or Stxlev>α however, Srxlev can be used to assess the quality of downlink transmissions (for example, uplink Pcomensation is not included in the calculation). Srxlev = Q rxlevmeas -(Q rxlevmin +Q rxlevminoffset )-Qoffset temp Stxlev can evaluate the quality of uplink transmission (for example, separately). Stxlev = Pcompensation, where Pcompensation = max((P EMAX1 -P PowerClass ),(P EMAX1_SUL -P PowerClass_SUL )). P Power_Class The value may differ depending on whether the WTRU is operating in two different RF chains (for example, one for frequencies above 6 GHz and the other for frequencies below 6 GHz). The threshold α may be broadcast in system information and / or configurable by the network.

[0091] WTRU is P EMAX1 It may receive additional values. P EMAX1_SUL This may apply to SUL carriers. EMAX1_SUL It can be received in SIB. P EMAX1_SUL This can be used in Pcompensation calculations as the maximum TX power level that a WTRU should use when transmitting over a SUL carrier.

[0092] When a WTRU performs cell reselection in an idle state, it may consider one of several factors. For example, a WTRU may consider a cell's support for SUL in its cell reselection rules. For example, when a WTRU decides whether to camp on a cell and / or measure in-frequency / inter-frequency neighbor cells, it may prioritize cells that have a SUL configuration (e.g., or provide access via SUL on cells without SUL). Such a decision may depend on one or more of the following, and such prioritization may be limited to certain types of WTRUs or WTRUs with certain capabilities (e.g., MTC WTRU vs. normal WTRU), limited to a WTRU in a certain state, such as the WTRU's current battery power, temporary capability limitations, etc., depending on the area the WTRU is currently roaming in, or depending on the WTRU's PLMN, and / or determined based on rules derived from information in the SIB broadcast by the cell or in RRCConnectionRelease or RRCConnectionReject messages.

[0093] For example, when camped on to a cell, the WTRU may provide various values ​​for the in-frequency search threshold (e.g., S(intraSearchP), S(intraSearchQ), etc.) depending on whether the serving cell has SUL. If the WTRU is camped on to a cell with SUL, the WTRU may use cell reselection parameters associated with SUL. If the WTRU is camped on to a cell without SUL, the WTRU may use cell reselection parameters associated with a cell without SUL. Such differences may allow the WTRU to initiate in-frequency measurements more quickly (e.g., to account for reduced UL coverage) when the cell does not support SUL. Cell reselection parameters may be area-specific (e.g., and not cell-specific). Therefore, cell reselection parameters associated with cells with SUL and cell reselection parameters associated with cells without SUL may be broadcast in the system information.

[0094] WTRU may apply an additional offset to the cell ranking criteria for determining the best cell, for example, depending on whether the cell has SUL or not. The offset may be provided in the system information. WTRU uses Qoffset / Qoffset for RUL and SUL cells. Temp Different values ​​are provided, and depending on whether a cell (e.g., serving or neighbor) supports SUL, such an offset can be applied to the cell ranking of such a cell.

[0095] The offset applied for cell ranking may be applied to the cell ranking criteria depending on the measured cell RX level (RSRP) of the DL in the cell and / or the presence of a SUL configured for that cell. For example, WTRU may apply an offset to a cell when configured with a SUL, and / or when the RX level (RSRP) or similar is below a threshold (e.g., only then). The offset applied to a cell configured with a SUL (e.g., a positive offset) may be a function of the received RSRP.

[0096] Cell reselection criteria can be implemented based on speed. For example, when high mobility levels and / or intermediate mobility levels are detected, WTRU may prioritize cells with configured SUL over cells operating with RUL only (for example, because the associated beamforming system may not be very robust to mobility).

[0097] Temporarily applied offset to the cell (Qoffset temp) can be scaled by an additional factor. This factor may (for example, also) be a function of the RSRP metric used in the cell ranking criteria for neighbors and / or serving cells. For example, a cell with a high RSRP and no configured SUL may not be preferred over a cell with a lower RSRP and configured SUL (and / or a cell with SUL may be preferred over a cell without SUL).

[0098] When high mobility or intermediate mobility is detected by WTRU, a positive bias (Q) is applied to the serving cell signal strength. Hyst ) is "Q hyst The speed-dependent scaling factor can be reduced by a configurable factor sf-High. In examples involving high mobility, if the serving cell supports SUL, WTRU may need to attenuate this bias reduction. For example, the bias reduction is "Q hyst The additional speed-dependent scaling factor can be reduced by the configurable factor sf-High_SUL. Furthermore, in some examples, if a serving cell is configured with SUL, the timer for cell re-selection can be scaled by an additional factor to increase the re-selection time.

[0099] The WTRU may receive SUL-related cell selection parameters in the System Information Block (SIB). The WTRU may determine whether a frequency carrier and cell support SUL (for example, to characterize the quality of the target cell, including the quality of the SUL carrier). For example, the WTRU may receive SUL-related cell selection parameters in the SIB of a camping cell that define the SUL configuration in neighboring cells. The WTRU may identify / distinguish SUL-supporting cells and apply the relevant SUL-related cell selection parameters in various selection / re-selection criterion evaluations. These values ​​may be one or more of the following: received as a neighboring cell list (for example, with cell IDs of various SUL-supporting cells); received as a 1-bit information list mapped to a neighboring cell list received in the SIB for cell-specific selection parameters (e.g., SIB5); received as an indication related to frequency carrier band configuration; based on stored information from previously detected cells; and / or required by the WTRU when proximity to SUL-supporting cells can be detected.

[0100] The WTRU may receive common parameters for intra-frequency and inter-frequency cell reselection in the SIB (e.g., SIB3). In addition, the WTRU may receive a list of SUL-supported neighbors (e.g., in the SIB) that contains the cell IDs of neighboring cells that support SUL. The WTRU may receive cell selection parameters for SUL relationships in the SIB (e.g., SIB5). The WTRU may receive a list (interFreqNeighCellList_SUL) that shows cells with cell selection parameters for SUL relationships to which the WTRU can apply SUL-specific cell selection parameters. The WTRU may receive a list mapped to IntraFreqNeighCellList in the SIB (e.g., SIB5) that shows, for example, 0 for neighboring cells that do not support SUL, 1 for cells in the list that support SUL, and / or a field that indicates which cell-specific parameters apply if the neighboring cell supports SUL.

[0101] A WTRU may maintain a SUL support list of previously visited cells that have a configured SUL, and may, for example, use an autonomous search function to detect previously visited cells whose cell ID and associated PLMN identification may be in the WTRU's SUL support whitelist. Proximity detection based on the autonomous search function may allow the WTRU to send a ProximityIndication_SUL message to indicate that it is in or out of proximity to one or more cells that support a SUL. This function may be enabled if the WTRU is in one or more of the following conditions: high, experiencing high attenuation on the downlink, and / or in a high mobility state (for example, only in these cases). If the WTRU detects one or more suitable cells in the SUL_Support_List, the WTRU may reselect one of the detected cells (for example, regardless of the frequency priority of the cell to which the WTRU is currently camped (for example, if the SUL cell in question is the highest-ranked cell on that frequency)).

[0102] A WTRU may maintain a SUL configuration in an RRC inactive state. A WTRU may maintain its own dedicated RUL / SUL configuration while in the RRC_INACTIVE state. Such maintenance of a configuration may allow a WTRU to perform UL transmissions while remaining in the RRC_INACTIVE state, and may prevent several WTRUs in the RRC_INACTIVE state from all using the same SUL configuration (e.g., the same pool of RACH resources). Rules may be needed to determine when a WTRU should release its RUL / SUL configuration and use the RUL / SUL configuration in RMSI instead. In some examples, a WTRU may maintain a RUL / SUL configuration and release such a configuration when a timer expires.

[0103] WTRU may release the RUL / SUL configuration when a mobility event occurs, for example, when re-selecting to a different cell, re-selecting to a different cell associated with a different RAN area, re-selecting to a different cell that does not support SUL, and / or when sending a Periodic RAN Location Area Update (RLAU) (for example, when it is sent to the same cell or a different cell).

[0104] The WTRU may release the RUL / SUL configuration during a resume procedure to a cell (for example, if it provides a new configuration for RUL / SUL). The WTRU may use a stored dedicated configuration for resume-related access and may replace the stored configuration with a new dedicated configuration provided (for example, in a resume message or reconfiguration following the resume procedure).

[0105] A WTRU may perform SUL procedures related to paging and initial access. For example, in response to paging, a WTRU may determine which uplink carrier should perform initial access on, for example, based on information provided in the paging message. A WTRU may receive indications to perform initial access on a SUL or RUL. For example, a WTRU may receive indications to perform initial access on a SUL or RUL in a paging message. Configured parameters for access on a SUL / RUL are provided in system information and / or stored in a dedicated configuration (e.g., an inactive state configuration). A WTRU may receive a paging record in which the signaled WTRU ID matches the WTRU's idle state ID. A WTRU may receive indications to perform initial access on a SUL or RUL (e.g., in RRC_IDLE). A WTRU may initiate an initial access procedure, for example, using stored system information related to the SUL / RUL configuration (e.g., RACH preamble / resource, carrier frequency, etc.). A WTRU may initiate the initial access procedure using stored information about the uplink carrier, which may be indicated in a paging message, for example. A WTRU (for example, in RRC_INACTIVE) may obtain the SUL / RUL configuration from system information while the WTRU was in RRC_CONNECTED, which may be stored during the transition to RRC_INACTIVE, or by dedicated RRC signaling.

[0106] WTRU may determine a UL carrier (e.g., SUL / RUL) based on a combination of information, such as (i) the measured quality of the DL carrier in the cell in which paging may be received (e.g., it may have been received) (e.g., RSRP, RSRQ, etc.), (ii) WTRU speed / rate, (iii) WTRU battery power, (iv) WTRU maximum UL transmit power, and / or (v) information that may be provided in the paging record in addition to one or more of the other information.

[0107] Regarding WTRU speed / velocity, in the example, if the user's mobility is fast (or above a threshold), the WTRU may select the SUL carrier. This can be more reliable and may allow the WTRU to transmit on a wider beam associated with the SUL (rather than the narrower beam associated with the RUL, which often results in beam changes, for example).

[0108] With respect to WTRU battery power, for example, if the result of the SUL receive power control + power adjustment for UL transmission in SUL (e.g., to compensate for the difference between the estimated path loss at the SUL frequency and the estimated path loss on the DL carrier in the cell) is a higher threshold than the RUL receive power control, the WTRU may select the RUL carrier. Conversely, if the RUL receive power control is a higher threshold than the SUL receive power control + power adjustment, the WTRU may select the SUL carrier. Thus, the WTRU may select the UL carrier that will result in the lowest power usage.

[0109] Regarding the WTRU's maximum UL transmit power, if the result of the SUL's receive power control + power adjustment is higher than the WTRU's maximum output power, the WTRU may select the RUL carrier.

[0110] The WTRU may select an indicated carrier (e.g., SUL or RUL) when one or more conditions (e.g., for any of the above quantities) can be met. The conditions may be based on, for example, values ​​of quantities above / below a threshold, which may be provided in system information, in the RRC configuration, and / or in paging messages. The NW may manage the load of UL resources on SUL / RUL while taking into account the type of data to be sent to the WTRU during DL (e.g., short data transmissions, low-latency data requiring highly reliable acknowledgments, etc.).

[0111] In the example, a WTRU may receive an RSRP threshold in the paging message that it can use to determine whether to perform initial access in response to paging on a SUL or RUL. For example, if the cell quality falls below a threshold provided in the paging message, the WTRU may perform initial access on the SUL; otherwise, it may perform initial access on the RUL. Such thresholds received in the paging message may override or take precedence over any other thresholds received from the cell in the system information.

[0112] The WTRU may determine which UL to use for access based on a combination of the above, without such information provided in the paging message, such as the WTRU battery power or the WTRU maximum UL transmit power.

[0113] A WTRU may use multiple thresholds for its decision criteria. For example, a WTRU may provide multiple RSRP thresholds to decide between initial access on a SUL or RUL. Each threshold may relate to a different access type or a similar factor related to access by the WTRU. By identifying the appropriate threshold based on the access type, the WTRU may determine which uplink (SUL or RUL) should be used for initial access. The WTRU may use an access on a SUL if the DL cell quality is below the relevant threshold, or on a RUL if the DL cell quality is above the relevant threshold. A WTRU may have thresholds (e.g., each of the thresholds) associated with one or more of the following factors: a WTRU type or WTRU class, which may be statically defined for the WTRU (e.g., MTC WTRU) or may be defined based on the capabilities of the WTRU; an access category or service type defined in a higher layer (e.g., NAS or application layer); various causes of connection establishment (e.g., tracking area update, DL data, resume from inactive state, RAN area update); the logical channel / priority of the data in the WTRU buffer at the time of access, and / or the amount of data in the buffer that is above or below the threshold (e.g., for a particular logical channel), for example, for access from an inactive state.

[0114] A WTRU may initiate access on a SUL or RUL where the described factor may not be related to the threshold. For example, a WTRU may initiate access on a SUL for a high-priority logical channel (e.g., URLLC) regardless of the threshold (e.g., it may always initiate access). In another example, a WTRU may (e.g., always) implement RLAU on a RUL. Such special cases may be made possible by certain rules, or a WTRU may receive a special value of the threshold (e.g., negative or positive infinity) that allows it to adhere to the described behavior.

[0115] A WTRU may perform initial access (e.g., one or more parts thereof) based on network indications, for example. For example, a WTRU may receive one or more indications from the network regarding which parts of initial access may be performed in the SUL / RUL. A WTRU may perform a PRACH transmission on the RUL / SUL (e.g., based on indications in a paging message) and transmit MSG3 on the SUL / RUL. A WTRU may determine or assume an authorization that may be received in MSG2 for the UL transmission of an MSG3 reference resource in the carrier indicated in the paging message for the transmission of MSG3. For example, the authorization in MSG2 may reserve a resource on the SUL if the paging indicates that MSG3 should be transmitted on the SUL, but may reserve a resource on the RUL if the paging message indicates that MSG3 should be transmitted on the RUL. WTRU may perform a PRACH transmission on RUL / SUL (for example, based on indication in the paging message) and / or transmit MSG3 on a carrier that may be indicated (for example, explicitly) in MSG2 (for example, with a CIF or similar flag in MSG2 MAC CE).

[0116] During initial access, the network may not have quality information (e.g., SRS transmission by WTRU) to properly select a UL (e.g., SUL or RUL). The WTRU may provide UL selection information during the initial access procedure, for example. The information that may be provided may include, for example, one or more of the following: (i) the measured quality of the cell's DL carrier (e.g., RSRP, RSRQ, etc.), (ii) the WTRU speed / rate, and / or (iii) the logical channel ID of the data that triggered the access. The WTRU may provide this information to the network, for example, by one or more of the following ways: (i) in an RRC message or MAC CE that may be included with MSG3, and / or (ii) implicitly (e.g., based on the selection of a RACH preamble / resource). The WTRU may be configured (e.g., in system information or by dedicated RRC signaling) to use a subset of the RACH preamble / resource when the WTRU speed may exceed a threshold. The network can use information (e.g., provided by the WTRU) to select, for example, an appropriate UL (e.g., SUL or RUL) to configure the WTRU. The WTRU may receive a configuration for a UL (e.g., in MSG4 of the initial access / resume procedure) which may include a UL for using the SUL and / or RUL for subsequent communication with the network.

[0117] When implementing response-driven paging, the paging indicator response performed on the SUL may not be used by the NW to select the DL beam for transmitting the paging record. The WTRU may transmit beam information on the SUL. For example, the WTRU may provide the NW with beam information for a DL beam on a non-beamformed UL carrier (e.g., the SUL), for example, during an initial access procedure. The WTRU may identify a beam, beam index, or synchronization signal block (SSB) index, for example, which may be relevant to the accurate reception of a paging indicator message. The WTRU may provide an identifier to the NW during a RACH procedure that may be performed on the SUL (e.g., at a non-beamformed frequency). For example, the information may be provided using one or more of the following procedures:

[0118] A WTRU may provide an identifier using data transmissions or data portions that can be attached to a PRACH preamble transmission (e.g., explicitly used). A WTRU may select a PRACH preamble / resource that may be associated with the identifier. A WTRU may be configured, for example, using a mapping of PRACH preamble / resources on a non-beamformed UL carrier (e.g., SUL) for a given beam index on a DL (e.g., a beamformed carrier) (e.g., through system information or dedicated RRC signaling). A WTRU may select a PRACH preamble / resource pair based on the configured mapping.

[0119] A WTRU may delay the transmission of the PRACH preamble by, for example, a time amount that may be relevant to the decoded index. A WTRU may be configured, for example, with a time delay (for example, specific) to be used for (for example, each) SSB beam index (for example, through system information or dedicated RRC signaling). A WTRU may select, for example, a time delay for the transmission of the PRACH preamble (for example, the number of subframes to wait) by a hardcoded amount that may be (for example, directly) relevant to the index (for example, index 1 = 1*x subframes, index 2 = 2*x subframes, etc.).

[0120] During a handover, the WTRU may determine which carriers are RUL / SUL. The WTRU may receive configurations for multiple (e.g., two) UL carriers in a handover (HO) command (e.g., one corresponding to SUL and another to RUL). The network may provide indications to show which configuration applies to which carrier. The WTRU may apply (e.g., subsequent) procedures / actions (e.g., during or after the completion of the HO command) depending on whether the HO can be performed on SUL or RUL. Knowledge of SUL / RUL may be derived by the WTRU, for example, by using one or more of the following: (i) (e.g., explicit) indications in the HO command, or (ii) the presence / absence of beam relation information in the L1 / L2 configuration and / or ARFCN. In the example (e.g., ARFCN), the WTRU may consider (e.g., all) frequencies below a reference ARFCN to be SUL. WTRU may, for example, determine the configuration related to SUL so that it has a lower ARFCN value when provided with separate complete configurations for SUL and RUL, or a complete configuration for one carrier and a partial configuration for another carrier.

[0121] There are various procedures that may vary depending on whether the WTRU completed the HO command on the RUL or on the SUL. These procedures include, for example, one or more of the following: (i) UL carrier selection for HO (e.g., the behavior discussed herein may depend on knowledge of whether the carrier is SUL or RUL, which may be determined as described herein); (ii) HO failure procedures (e.g., the WTRU may perform different actions upon HO failure, which may depend on whether the HO can be performed first on the SUL or the RUL); (iii) RLF / S-RLF procedures (e.g., the WTRU may perform different actions when triggering an RLF / S-RLF, or a particular form of RLF / S-RLF, depending on whether the HO can be performed via the SUL or the RUL); (iv) re-establishment procedures (e.g., in the case of a failed HO) or in the case of an RLF that follows the HO); (v) resume procedures that follow a suspend; (vi) UL data and / or UL RRC routing and / or (vii) system information requests. The WTRU may receive a display of one or more of the procedures described above as part of an HO command and / or while the WTRU is in an RRC connection.

[0122] The WTRU may receive uplink carrier selection information (e.g., SUL and / or RUL) from the network in an HO command, and based on this information, may select the uplink on which to perform the initial access. For example, the WTRU may be provided with the carrier to be used (e.g., SUL or RUL) to perform the initial access during an HO. The display may be an explicit indicator of which carrier to use. The network may provide UL configurations for SUL and RUL (e.g., in an HO command or in system information). The WTRU may perform the initial access during an HO using the indicated carrier configuration.

[0123] A WTRU may perform an HO to a carrier that may contain the information necessary to perform initial access (e.g., in an HO command). A WTRU may receive a complete configuration (e.g., SUL or RUL) (e.g., a single one) from the network in an HO command. A WTRU may perform initial access on a carrier that may be associated with the configuration. The configuration may consist of, for example, initial access parameters (e.g., dedicated / common RACH resources). The configuration may also include (e.g., further) configurations for UL carriers (e.g., L1 configuration, L2 configuration, etc.) to be used during operation in RRC_CONNECTED mode. A WTRU may receive (e.g., additional) reduced configurations for another UL carrier (e.g., RUL or SUL) that may include, for example, ARFCN and SRS configurations for UL SRS transmissions that follow the HO command (in addition to, for example, a single complete configuration). A WTRU may select a carrier that may provide a complete configuration for performing initial access (e.g., in this case) and configure SRS (e.g., SRS only) on another carrier.

[0124] A WTRU may perform initial access during HO to a carrier (e.g., SUL / RUL). A WTRU may perform or configure UL operations during and / or after HO completion on another carrier (RUL / SUL). A WTRU may receive a RACH configuration for SUL (for example in this case) and a full configuration (e.g., L1, L2) for RUL, or vice versa.

[0125] The WTRU may, for example, determine which carrier (e.g., SUL or RUL) should perform the HO based on the state of the WTRU in the source cell (e.g., prior to the HO command). The WTRU may be configured in the source cell with multiple (e.g., two) separate configurations (e.g., RUL and SUL), but may be configured to use (e.g., a single) configuration (e.g., only that) during the time of receiving the HO command. The WTRU may determine or assume, for example, that the same UL (e.g., RUL or SUL) can (e.g., should) be used in the target cell. The WTRU may perform the initial access to the target cell using the UL carrier. Alternatively or additionally, the WTRU may be configured in the source cell with SUL (e.g., only that), and the choice made by the WTRU regarding UL for the initial HO may be to select SUL in the target cell (e.g., the WTRU may offer both configurations in the HO command). The WTRU may determine or assume, for example, that the configuration in the HO command (to be used in, for example, the target cell) relates to the same type of UL carrier (e.g., RUL or SUL) as the last configuration in the source cell. The WTRU may be configured to use both SUL / RUL in the source cell (for example, in addition or alternative, according to, for example, NW scheduling). The WTRU may use a different procedure (for example, as described herein) to select between SUL / RUL during the HO (for example, in this case). The WTRU may receive configuration information for SUL and RUL in the HO command.

[0126] A WTRU may receive a common SUL configuration for source and target cells. A WTRU may determine or assume that the actual SUL configuration of the target cell is the same as the SUL configuration of the source cell. A WTRU may make such determinations or assumptions based, for example, on one or more of the following: (i) the configuration, (ii) the relationship between the target cell ID and the source cell ID, and / or (iii) the representation in the HO command (e.g., explicit representation or implicit representation (e.g., by the absence of a SUL configuration)). A WTRU may, in some cases, utilize the source cell's SUL configuration during and after the HO command until the WTRU is reconfigured with the new SUL configuration (e.g., through dedicated RRC signaling or during the collection of system information).

[0127] The WTRU may determine the uplink (SUL and / or RUL) based on the factors determined by the WTRU. The WTRU may provide a complete configuration for SUL and RUL. The WTRU may select a carrier for initial access to HO based on one or more conditions that can be measured / determined in the WTRU, such as (i) DL cell quality such as RSRP, RSRQ (compared to a threshold that can be configured or hardcoded, e.g.), (ii) WTRU speed / rate (compared to a threshold that can be configured or hardcoded, e.g.), (iii) WTRU battery power (compared to a threshold that can be configured or hardcoded, e.g.), (iv) WTRU maximum UL transmit power (compared to a threshold that can be configured or hardcoded, e.g.), (v) logical channel ID of data that may be pending in the WTRU buffer, and / or (vi) beams on which the WTRU may be receiving HO commands.

[0128] In the example of (for example, the logical channel ID of data that may be pending in a WTRU buffer), a WTRU may perform UL access to a SUL when there is data in one or more WTRU buffers that may correspond to (for example, a set of) logical channels indicating (for example, a) priority or delay criticality. A priority level (for example, the lowest) may be configured by the network (for example, in dedicated or broadcast signaling).

[0129] In an example (for a beam on which a WTRU may have received an HO command), the WTRU may be configured with a set of beam IDs for initial access to the target cell and a correspondence of beam IDs to SUL or RUL. The WTRU may, for example, determine which UL carrier to use based on the beam ID on which the HO command was received. The configuration may be target cell specific.

[0130] A WTRU may select one of a set of target cells based on SUL / RUL criteria. A WTRU may, for example, provide a target cell configuration for one or more cells in an HO command. A WTRU may, for example, perform an initial access to the target cell for an HO upon receiving an HO command, based on measurements performed at each candidate target cell. A WTRU may perform an HO to a target cell that may have a better DL cell measurement (e.g., RSRP) at the time of the HO command. A WTRU may select a target cell for which the RUL / SUL selection (for example, in the context of SUL / RUL selection) may result in the WTRU's selection of RUL.

[0131] The load on SUL can be reduced, for example, when HO may prioritize cells where WTRU may not require the use of SUL at HO time. Decisions by WTRU (compared to, for example, NW decisions) may be more accurate (for example, because measurements may be performed at HO command time) and may be combined with other factors (e.g., WTRU-specific factors) that NW may not have access to (e.g., speed, beam information, etc.).

[0132] A WTRU may use a timer-based fallback to SUL during an HO procedure. A WTRU may initiate an HO procedure to RUL and, for example, fall back to performing an HO to SUL depending on the conditions. For example, a WTRU may initiate an HO to RUL. A WTRU may be configured with a timer that determines when to fall back to SUL. A WTRU may start the timer when it receives an HO command. The timer may be started, for example, when the WTRU selects RUL for initial access during an HO (for example, only then). A WTRU may perform an HO to RUL while the timer is running. A WTRU may, for example, attempt an HO to the target via SUL when the timer expires. The timer may or may not be equivalent to an HO failure timer (e.g., T304).

[0133] In an example (for example, an additional or alternative example) (which may be used in combination with another example), the WTRU may be configured (for example, further) with a second timer. The second timer may define the amount of time the WTRU can attempt an HO on the SUL before an HO failure may be declared. The WTRU may start a timer, for example, when it begins to fall back to the SUL. The WTRU may attempt an HO to the target cell via the SUL, for example, until the second timer is running. An HO failure may be declared, for example, when the second timer expires.

[0134] A WTRU may implement a fallback to a competition-based (common) resource during a HO. For example, following a failure to perform the HO on a dedicated (CFRA) resource provided by the network, the WTRU may fall back to a competition-based random access resource, and may select such a resource on either a SUL or a RUL. The WTRU may base its selection decision on whether the dedicated resource was provided on a SUL or on a RUL.

[0135] A WTRU may select the same UL (SUL or RUL) on which it received a dedicated resource for CFRA. For example, if a WTRU receives a dedicated resource on a RUL / SUL and an HO fails on the dedicated resource, the WTRU may fall back on a competition-based resource on the RUL / SUL. A WTRU may use (for example, always use) such a resource, assuming that a UL resource associated with a SUL is provided by the network. A WTRU may use a RUL resource if a SUL resource is not provided. A WTRU may determine which UL carrier to use based on the measured DL quality at the time of an HO or HO failure on a dedicated resource. For example, if a WTRU is provided with a common resource on both SUL and RUL in an HO command, the WTRU may fall back to the SUL resource if the DL cell quality falls below a threshold, and otherwise may fall back to the RUL. In the criteria described, an HO failure on a dedicated (CFRA) resource may include a failed RACH procedure or attempt, or it may include a beam associated with a dedicated RACH resource that falls below a configured threshold.

[0136] WTRU may base its fallback to SUL on prioritizing beam compatibility and / or no-conflict access. WTRU may, for example, fall back to attempting HO on SUL (following an initial attempt on RUL) when there are no longer any beams on RUL that can satisfy (e.g., specific) compatibility criteria.

[0137] Alternatively or additionally, the WTRU may perform an HO (for example, initially) on one or more dedicated resources (e.g., beams) of the RUL, such as those provided by an HO command, when it can be measured that one or more of those beams exceed the relevant threshold (e.g., provided in the HO command). The WTRU may determine (before or during an HO attempt to a target on a dedicated RACH resource such as a beam) that the quality of all dedicated RACH resources falls below a configured threshold. The WTRU may initiate an HO procedure on the SUL (e.g., using a SUL configuration). The WTRU may (for example, further) perform a fallback to the SUL (e.g., only) when it can provide a dedicated RACH configuration (e.g., a non-conflicting resource) on the SUL (e.g., under such conditions).

[0138] In an example (for example, an additional or alternative), a WTRU may perform an HO (for example, initially) on one or more dedicated resources (e.g., beams) on a RUL (e.g., provided in an HO command) when, for example, one or more of the beams have a quality above a threshold. A WTRU may use beams in a common configuration of the RUL (e.g., related to competition-based random access) when, for example, one or more beams / resources may have a quality above a threshold (e.g., the same or different), or when, for example, no beams have a quality above a threshold. A WTRU may fall back to performing initial access for an HO on a SUL (e.g., then) when, for example, none of the beams / resources on the RUL (e.g., common or dedicated) have a quality above a threshold.

[0139] A WTRU may request a change in the UL carrier based on one or more factors. A WTRU may request that the NW change the UL. A WTRU may be configured to utilize (for example, only one) UL (e.g., RUL). A WTRU (for example, when configured) may request that the network change its UL to another carrier (e.g., SUL).

[0140] The initiation of a UL request or change may be based on one or more conditions, such as (i) the DL quality of the cell, (ii) the WTRU speed, (iii) the current WTRU battery power, and / or (iv) the arrival of high-priority data. For example, a WTRU may request or change its UL (e.g., from RUL to SUL) at some point after receiving a reconfiguration command, for example, when the measured quality of the DL may fall below a threshold (e.g., configured by the network). For example, a WTRU may request or change its UL (e.g., from RUL to SUL) when the WTRU speed may (e.g., begin to exceed) a network-configured threshold. For example, a WTRU may request or change its UL (e.g., from RUL to SUL) when the remaining WTRU battery power may fall below a threshold (e.g., configured by the network).

[0141] For example, a WTRU may request or change its UL (e.g., from RUL to SUL) if, for example, a packet may arrive at the WTRU on a logical channel or radio bearer, and the packet's priority may exceed a priority level. A WTRU may trigger a UL change (e.g., from RUL to SUL) if, for example, a new data packet may arrive at an SDAP / PDCP layer that may be associated with a specific QoS level or mapped to a specific radio bearer. The QoS levels and / or radio bearers (which may trigger the change procedure) may be configured by the network.

[0142] In (for example, additional or alternative) examples (which may be used in combination with other examples), the WTRU may provide (for example, further) the time validity and associated conditions of the SUL configuration. The WTRU may start a timer (for example, upon receiving a conditional configuration) and, for example, evaluate one or more conditions while the timer is running. The WTRU may delete the received configuration and stop evaluating one or more associated conditions (for example, upon the expiration of the timer).

[0143] WTRU behavior can be adapted based on triggering conditions. For example, a WTRU may notify lower layers that it needs to switch to a SUL (for example, in the example above). The WTRU may then initiate (for example, further) lower-layer procedures that may be related to notifying the NW of the UL switch. The upper layers may initiate one or more lower-layer procedures, such as (i) initiating a RACH procedure or a RACH-like procedure on the SUL, (ii) sending an RRC message on the currently configured UL (e.g., RUL), (iii) sending a PUCCH (e.g., SR or other indication) on the SUL (e.g., when resources may be configured), and / or (iii) sending an RRC message on the master node (e.g., eNB / gNB) when, for example, the WTRU may be configured using a DC, and / or when the RUL / SUL configuration may be related to sending on a secondary node (SN) (e.g., gNB).

[0144] A WTRU may transmit a switching indication to the network. The indication may be, for example, an RRC message transmitted to the network. The indication may provide information such as one or more of the following: (i) an indication of a switching request (for example, to distinguish it from a RACH procedure for other purposes), (ii) the cause of the switching (for example, the conditions satisfied that trigger the switching), (iii) measurements that may be related to the switching (for example, measurements such as DL quality, WTRU speed, etc.), and / or (iv) the expected / determined duration for the use of the SUL and subsequent switching back to the RUL (or vice versa).

[0145] For example, a WTRU might send a switchover indication message in MSG3 for a RACH procedure or a RACH-like procedure to SUL, for example, to indicate a switchover to SUL to the network. In an example (for example, an additional or alternative), a WTRU might send a switchover indication message as an RRC message on RUL, or as an RRC message to MN (for example, when the switchover to SUL may be related to SN).

[0146] The WTRU may include data and / or signaling (included during the switchover indication) in MSG3. In the example, the WTRU may wait for acknowledgment from the NW, and when the WTRU is switched to the SUL (by DCI or RRC configuration), it may transmit data and / or signaling (which may, for example, trigger the transmission of the switchover indication via the SUL).

[0147] The WTRU may receive a failover confirmation. For example, the WTRU may receive a failover confirmation from the network (for example, following the transmission of a failover confirmation message). The failover confirmation may confirm or reject the WTRU's use of the SUL. The WTRU may commence using the SUL (for example, for sending data) (for example, upon receiving a positive confirmation). The WTRU may receive (for example, in the failover confirmation message) (for example, further) configurations that may be used on the SUL (e.g., L1 / L2). Alternatively or additionally, the WTRU may receive failover confirmation messages in MSG4 for RACH procedures that may be performed on the SUL.

[0148] UL changes / reconfigurations may be conditional. Network-based decisions for changes (e.g., from RUL to SUL) may not handle fading / blocking that occurs faster than the SRS period, and may be (e.g., primarily) based on WTRU transmissions of SRS and DL signaling (e.g., RRC, MAC / DCI) for reconfigurations, which may affect the successful transmission of where URLLC data needs to be sent within the UL.

[0149] A WTRU may modify a UL based on configured conditions, for example. For example, a WTRU may be provided with the configuration of a SUL (for example, in dedicated RRC or system information) and may initiate or trigger a switch from using a RUL to using a SUL while operating in RRC_CONNECTED mode, for example, after receiving a reconfiguration or switching message. The switch may occur, for example, as a result of one or more conditions being satisfied in the WTRU. The conditions may be, for example, the same conditions for requesting a switch to the network. A WTRU may apply a switch or reconfiguration, for example, when it can (for example, does) occur within a configured time period following the receipt of the switch or reconfiguration (for example, only then). A WTRU may receive conditions (for example, further) as part of the configuration of a SUL. A WTRU may utilize a RUL for a time period during which the conditions related to the switch can be satisfied. A switch from SUL to RUL may be initiated, for example, when the conditions can no longer be satisfied. A WTRU may remain configured on a SUL for a predefined or configured time period (for example, as an additional or alternative), after which a WRTU may revert to utilizing the previous configuration of the RUL. A WTRU may revert to utilizing the RUL (for example, as an additional or alternative) based on different conditions that may relate to the initial conditions for utilizing the SUL (for example, the successful transmission of a high-priority packet).

[0150] A WTRU can be configured using uplink semi-persistent scheduling across SUL / RUL. A WTRU can be configured using fast relocation of UL SPS from RUL to SUL and vice versa. A WTRU can be configured using a semi-persistent scheduling configuration applicable to RUL and SUL. In an example, a WTRU can be configured using (e.g., a single) SPS configuration that may be related to RUL and SUL. In an (e.g., additional or alternative) example, a WTRU can be configured using multiple (e.g., two) separate SPS configurations (e.g., the first SPS configuration may be related to RUL and the second SPS configuration may be related to SUL).

[0151] The WTRU may be configured (for example) further to determine whether UL authorizations associated with an SPS configuration are applicable to RUL and / or SUL. For example, the WTRU may (for example) explicitly signal that one or more configured SPS authorizations are applicable to a (for example) specific UL carrier (for example, RUL or SUL).

[0152] A WTRU may be configured to perform (e.g., fast) relocation of UL SPS from RUL to SUL and vice versa, for example, based on implicit rules or explicit commands. Relocation may refer to interrupting an SPS configuration applicable to a first UL carrier and applying an SPS configuration applicable to a second UL carrier.

[0153] For example, a WTRU may be configured to suspend the SPS configuration applicable for a RUL and apply the SPS configuration applicable for a SUL when it receives a reconfiguration command, for example, in MAC CE, RRC signaling, or L1 signaling.

[0154] In (for example, additional or alternative) examples, a WTRU may autonomously perform a relocation, for example, when a UL SPS is configured for a SUL and / or when one or more pre-configured conditions are met. Conditions may include, for example, determining DL quality below a threshold, DL path loss below a threshold, or when UL SPS retransmissions exceed a predetermined threshold. Conditions that can be pre-configured may include other trigger conditions that may be applicable for SUL switching.

[0155] WTRUs can be configured, for example, to use SPS UL authorization on RULs and SULs for increased reliability / diversity. WTRUs can also apply overlapping or alternating transmissions using predefined hopping patterns across SULs and RULs.

[0156] A WTRU may confirm an SPS relocation. A WTRU may be configured to acknowledge (e.g., explicitly) or indicate (e.g., implicitly) an SPS relocation, for example, by transmitting MAC CE, RRC signaling, or L1 signaling (e.g., SRS transmission) on the relocated UL carrier. For example, upon receiving an SPS relocation command from RUL to SUL, a WTRU may transmit an acknowledgment on the SUL carrier.

[0157] A WTRU can be configured to receive and / or dynamic authorization for SPS resources. A WTRU can be configured with SPS resources (Type 1 or Type 2 resources) on one or both ULs. A WTRU can receive (for example, further) dynamic authorization on the same transmission interval for one of the two uplinks configured in the WTRU.

[0158] Dynamic authorization can enable transmit redundancy. For example, a WTRU receiving a UL authorization on a non-SPS carrier (e.g., a dynamic UL authorization on a SUL when SPS is configured on a RUL, or vice versa) may perform duplicate transmission of data (e.g., transport blocks) on both the SUL and the RUL. The WTRU may be configured with one or a set of logical channels to which such duplicate behavior should apply. The WTRU may perform such duplicate behavior if, for example, there is a data hold on such a logical channel at the time of receiving such dynamic authorization, and may, in some cases, revoke the SPS authorization otherwise.

[0159] Dynamic authorizations can allow for the revocation of a set of authorizations. For example, a WTRU receiving a UL authorization on a non-SPS carrier may revoke the current authorization as well as several subsequent SPS authorizations. A dynamic authorization received by a WTRU (resulting in the revocation of an SPS authorization) may need to be sent over the same transmission interval as one of the SPS authorizations. The number of SPS authorizations to be revoked may be determined by one or more of the following: (i) The WTRU may revoke a number of SPS authorizations indicated (by some value) in the dynamic authorization itself (e.g., a value in the DCI message). After skipping or revoking a signaled number of authorizations on a UL carrier configured with SPS, the WTRU may begin using authorizations based on the same configuration. (ii) The WTRU may revoke all SPS authorizations until it receives network signaling from the network that makes the SPS authorizations reusable.

[0160] In the example, network signaling that makes SPS authorizations reusable could take the form of dynamic authorization on a UL that has configured SPS resources. For example, a WTRU with an SPS configured on a RUL may receive one of its SPS authorizations and a dynamic authorization for a SUL on the same transmission interval. The WTRU may revoke its SPS authorization, as well as all further SPS authorizations on the RUL, until it again receives another dynamic authorization for a UL resource on the RUL.

[0161] In the example, the network signaling that makes SPS authorizations reusable could be in the form of a DCI message used specifically to reactivate SPS resources. This could be a DCI used for SPS activation (e.g., a DCI targeting a CS-RNTI) or some other dedicated network signaling. For example, a WTRU with an SPS configured on a RUL might receive a dynamic authorization for one of its SPS authorizations and for a SUL on the same transmission interval. The WTRU could revoke that SPS authorization, as well as all further SPS authorizations on the RUL, until it receives an SPS activation message (e.g., a DCI message targeting a CS-RNTI) to reactivate a previously configured SPS authorization.

[0162] A WTRU may revoke all SPS authorizations as long as the WTRU's measured DL RSRP falls below a threshold. The WTRU may indicate to the NW, through some UL transmission (e.g., RACH or SRS-like), when the DL RSRP may move above the threshold and the WTRU will resume using SPS authorizations.

[0163] The described behavior of WTRU may depend on which UL (SUL or RUL) the SPS resource is configured for. The described behavior of WTRU may also depend on the type of SPS resource (e.g., type 1CS or type 2CS).

[0164] In an example where dynamic authorization revokes a set of authorizations, if the SPS resource is configured on a RUL and the dynamic authorization is for the RUL, the WTRU may revoke the SPS authorization as described. If the SPS resource is configured on a SUL and the dynamic authorization is provided for the RUL, the WTRU may revoke a single authorization (e.g., just that one) (as in LTE).

[0165] In an example where dynamic authorization revokes a set of authorizations, the trigger for reusing or reactivating SPS authorizations may depend on whether the SPS authorizations are related to a Type 1 CS (e.g., an RRC defines the authorization and no PDCCH is required) or a Type 2 CS (e.g., an RRC defines the periodicity of CS authorizations and a PDCCH targeting a CS / SPS-RNTI activates the CS authorizations). In Type 1, a WTRU may reactivate SPS authorizations following revocation (e.g., when it receives a dynamic authorization for a UL on a RUL). In Type 2, a WTRU may reactivate SPS authorizations following revocation (e.g., when it receives a DCI targeting a CS / SPS-RNTI that activates SPS).

[0166] Various mechanisms can be used to support the routing and reliability of control signaling (e.g., RRC signaling).

[0167] A WTRU may be configured to perform RRC message duplication on RULs and SULs. The WTRU RRC layer may notify lower layers that certain RRC messages being passed on may (or should) be duplicated on RULs and SULs. A WTRU may determine whether to perform RRC message duplication on RULs and SULs based on one or more of the following: (i) the WTRU is configured with RULs and SULs, (ii) the WTRU is configured with RULs and SULs and both are active (e.g., PUSCH scheduling is possible on either UL), (iii) the DL cell quality of the cells in which RULs and SULs are configured is below or above a threshold, (iv) the RRC message is of a specific type (e.g., a measurement report), and / or (v) the measurement associated with the measurement report meets the conditions for message duplication.

[0168] A WTRU (e.g., an RRC layer) may indicate when the conditions for duplication are no longer valid. Lower layers of a WTRU may perform duplication of (e.g., all) RRC messages during the time duplication is valid. For example, a lower layer may perform duplication by sending it in a RUL and SUL when scheduled on either carrier. A lower layer may (e.g., additionally or alternatively) perform procedures to notify the network of resource needs in both a RUL and a SUL (e.g., RACH procedure, SR procedure, etc.) when, for example, a WTRU is configured on both but active on only one, or when a WTRU is configured on either a RUL or a SUL.

[0169] WTRUs and / or networks may switch UL routes for RRC signaling. A WTRU may be configured to switch UL routes associated with transmitting RRC signaling (from RUL to SUL, or vice versa). For example, a WTRU may be configured to transmit RRC signaling over one of two ULs at a given time and may be configured to change the UL for such messages based on some event. A change in UL may be applicable to (for example, only to) RRC signaling. A change in UL may be applicable to (for example, only to) certain types of RRC messages, such as measurement reports, measurement reports triggered by a certain type of event, and / or measurement reports that satisfy some conditions regarding measurement quality, triggering time, etc.

[0170] In the example, a WTRU may change the UL for sending RRC messages by sending an RRC message when it is scheduled on a SUL (e.g., only then) or when the NW switches the WTRU to a SUL. A WTRU may proactively request a UL switch to another UL in order to send RRC messages on that other UL. A WTRU may send a switch indication (e.g., RACH on a SUL) when it requires a change of UL for RRC signaling. A WTRU may indicate that such a switch applies to (e.g., only to) RRC signaling (e.g., it may further indicate this).

[0171] WTRU may determine that an RRC message should be transmitted on a different UL (e.g., switching from RUL to SUL) based on one or more of the following conditions: (i) the measured DL quality of the cell is below (e.g., or above) a threshold; (ii) the WTRU speed is below (e.g., or above) a threshold; (iii) the maximum UL transmit power is below (e.g., or above) a threshold; (iv) the WTRU battery power is below (e.g., or above) a threshold; (v) the RRC message is transmitted on SRB1 / SRB2; and / or (vi) the RRC message is of a specific type (e.g., a measurement report) with specific criteria (e.g., related to a specific measurement event).

[0172] A UL route may be selected for RRC signaling in dual connectivity (DC). A WTRU can be configured using any form of DC (e.g., NR-NR DC, EN-DC, etc.). A WTRU may determine the UL route for RRC messages based, for example, on the DL quality of a PSCell or SCell on the SN. A WTRU may send RRC messages to the SN (for example, when the DL quality on the SN may be acceptable). A WTRU may send RRC messages to the MN (for example, in some cases) when the DL quality on the SN may be unacceptable.

[0173] The WTRU may be configured using SRB3 and may split SRB1 / 2 (e.g., anchored in MN). The WTRU may transmit an RRC message on SRB3 when, for example, the measured DL quality of the SN PSCell may exceed a threshold (e.g., configured). The WTRU may transmit an RRC message on SRB1 / 2 when, for example, the measured DL quality of the SN PSCell may fall below a threshold. The WTRU may encapsulate an NR RRC message within an LTE RRC message (e.g., when transmitting an RRC message on SRB1 / 2) when the WTRU is configured using EN-DC. The WTRU may (e.g., further) apply a determination (e.g., only) on an RRC message that may be transmitted (e.g., normally) on SRB3 (e.g., a measurement report relating to a measurement configuration configured by an NR SN).

[0174] In an example (for example, an additional or alternative), a WTRU (for example, configured with SRB3 and split SRB1 / 2) may, for example, have (for example, only) a RUL configured with or activated in SN using a RUL in SN, and send an RRC message (for example, addressed to SN) on SRB1 (for example to MN via a transparent container) when the DL quality of SN (for example PSCell) falls below a threshold configured for RUL use (for example, a threshold for determining whether RUL or SUL can be used for initial access, or another threshold for determining whether RUL or SUL can be selected).

[0175] The WTRU and / or network may have radio link fault (RLF) and associated error procedures for SUL. The WTRU may be configured to send beam recovery requests when it detects, for example, a problem with one or more uplink and / or downlink beams. For example, a beam fault may be detected in the WTRU (for example, by a lower layer). The WTRU may initiate a random access (RA) procedure for beam fault recovery (BFR). UL transmission on a normal frequency carrier may not allow the WTRU to successfully transmit a preamble associated with a selected reference signal to the gNB.

[0176] A WTRU (for example, when performing random access for BFR) may apply one or more of the following procedures: performing BFR first in the RUL and then in the SUL; performing BFR in the SUL (for example, immediately after a beam failure is declared if the SUL is configured); selecting a UL based on the configuration of dedicated RACH resources on either uplink (for example, the WTRU utilizing a UL that has a valid dedicated RACH configuration in it); and / or sending a preamble in the RUL and receiving permission for both ULs.

[0177] A WTRU may perform a BFR first in the RUL and then in the SUL. In such cases, performing a BFR in the SUL may be used as a fallback procedure after certain conditions have been met on the RUL. For example, a WTRU may be triggered to perform a BFR in the SUL, when a BFR is performed in the RUL, one or more of the following may occur: a certain timer may expire, a certain number of attempts may be reached, and / or a certain transmit power may be reached.

[0178] In an example where a WTRU selects a UL based on the configuration of a dedicated RACH resource on either uplink, the WTRU may first perform a no-contest RA (CFRA) in the UL (e.g., RUL or SUL), where one or more of the following may occur: the dedicated RACH resource is configured / available, and (e.g., in case of failure) the WTRU may perform a contest-based RA (CBRA) in the RUL. If CFRA resources are configured on both uplinks, they may be given priority, and the WTRU may perform CFRAs in order of priority.

[0179] The purpose of the beam fault recovery request procedure may be to inform the serving gNB of a new SSB or CSI-RS when a beam fault has been detected on the serving SSB / CSI-RS. Transmission in a configured SUL may not allow the gNB to identify the strongest beam being transmitted by the preamble. Indication to the NW may be necessary to determine which SSB or CSI-RS in the DL can (and should) be used in a DL transmission.

[0180] The indication to the network (e.g., gNB) may be handled by one or more of the following: the configured preamble in the SUL may be mapped to the SSB or CSI-RS of the same cell; the WTR may indicate to the network which DL beam is the strongest (e.g., by transmitting the beam ID associated with the strongest SSB or CSI-RS in msg3); and / or the WTRU may send an RRC message on the SUL to the gNB that indicates the strongest DL beam or contains the associated measurement results.

[0181] A WTRU may be configured with a dedicated RACH resource mapped to an SSB and / or CSI-RS resource in the cell. The WTRU may select a preamble in the SUL that may be associated with a specific SSB or / CSI-RS beam that can receive RAR and msg4.

[0182] The WTRU may transmit a preamble in the beam on a normal frequency carrier and may receive permission for both SUL and RUL (e.g., in msg2). If a dedicated RACH resource is configured on only one uplink, the WTRU may transmit a preamble on the carrier on which the dedicated resource is configured. If a dedicated RACH resource is configured on both uplinks, the WTRU may attempt a CFRA on a suitable beam associated with the dedicated RACH resource in RUL (if available) and fall back to SUL (e.g., only if one of the defined conditions is met). If a dedicated RACH resource is configured on both uplinks, the WTRU may attempt on SUL (e.g., if a suitable beam associated with the dedicated RACH resource in RUL is not available) before falling back to a CBRA in RUL.

[0183] A WTRU may be configured using thresholds for beam compatibility criteria related to CSI-RS or SSB. If the RSRP associated with any beam exceeds the threshold, the WTRU may perform a CBRA (e.g., and, in case of failure, declare an RLF). In the example, the WTRU may be configured with a second threshold higher than the beam compatibility threshold (for example, allowing the WTRU to select a SUL carrier for a beam fault recovery request before performing a CBRA in a RUL).

[0184] The WTRU can monitor the quality of beams associated with SSB and CSI-RS in the cell. If the RSRP of one or more beams exceeds a suitability threshold (but not a second threshold, e.g., SUL), this may indicate to the gNB that the downlink transmit quality is good enough for DL ​​reception in the current bandwidth part and frequency configured for the WTRU, but insufficient for preamble transmit at RUL. The WTRU may consequently use SUL for RA procedures.

[0185] Radio link failures can occur on the Master Cell Group (MCG). A WTRU may be configured using UL / RUL on the MCG. The conditions for triggering an RLF may depend on the configuration and / or activation state of the RUL / SUL. A WTRU that triggers an RLF on the MCG (for example in LTE) may initiate a re-establishment procedure. An RLF may be triggered by one or more of the following, for example: (i) the maximum number of RLC retries reached for the MCG DRB, (ii) a random access problem that may be indicated by the MCG MAC, and / or (iii) T310 expiration, which may come after the detection of a synchronization problem that may be detected in L1.

[0186] A WTRU may behave differently in response to triggering conditions for one or more RLF relationships, for example, based on the RUL / SUL configuration. WTRU behavior may depend, for example, on the RUL / SUL configuration and / or activation (e.g., whether RUL and SUL are fully configured in the WTRU, or only one is configured by RRC, and / or whether the WTRU can currently be indicated to use only a single UL). The WTRU may trigger an RLF (for example, in response to relevant conditions that may correspond to an RLF), initiate re-establishment, or perform one or more (e.g., combinations) alternative or additional actions. Alternative / additional actions may include, for example, one or more of the following: (i) initiating a switch or request to use a SUL (based on one or more examples discussed, for example, with respect to the HO procedure), or indicating a lower layer to initiate such a procedure; (ii) starting a timer and waiting for a NW command to switch to another UL (e.g., SUL), and, for example, triggering an RLF following the expiration of the timer without receiving a command from the NW, and subsequently re-establishing; (iii) starting an RRC message on the SCG SRB (for example, when the WTRU has a configured SCG SRB); (iv) initiating an action on another UL (e.g., SUL) that has generated a triggering condition (e.g., performing a random access or retrying a transmission on an RLC); and, if another UL may now be configured, (iv) starting a timer, in the meantime, during which the WTRU may continue DL receiving on the PCell, but may delay UL transmission on the PCell, until it can receive a NW command (e.g., RRC, MAC CE, or L1) to switch the UL to a different carrier. A WTRU may, for example, declare an RLF and initiate a re-establishment following the expiration of a timer due to no command received from the NW, and / or indicate (e.g., to lower layers) to reset counters associated with the RLF (e.g., the number of RLC retries, the number of PRACH transmission attempts).

[0187] A WTRU may, for example, be configured with RUL and SUL, and when both are active (for example, only then), it may trigger an RLF under one or more RLF triggering conditions and initiate a re-establishment procedure. A WTRU may, for example, be configured with RUL (for example, only) or be configured with both RUL and SUL but may be instructed to use RUL (for example, only), and may initiate a RACH procedure or a RACH-like procedure on SUL. A WTRU may use a RACH resource associated with SUL that is dedicated or configured in broadcast signaling to initiate a RACH procedure on SUL.

[0188] A WTRU may trigger an RLF and initiate re-establishment, for example, when the WTRU is configured using only RULs, or when it is configured using both RULs and SULs but is instructed to use only RULs. A WTRU may trigger an RLF and initiate re-establishment, for example, when the conditions satisfying an RLF are related to a DL problem (e.g., IS / OOS) (e.g., only at that time). A WTRU may perform one or more of the actions (e.g., those described above) when the RLF triggering conditions are related to reaching the maximum number of RLC retransmissions or to a RACH problem indicated by a MAC entity.

[0189] WTRU can implement various different combinations of RUL / SUL configuration and / or activation states, results, and RLF triggering conditions depending on the action.

[0190] WTRU may trigger an RLF based on DL cell quality compared to a threshold. For example, in an (additional or alternative) example (which may be used in combination with one or more other examples), WTRU may have different behavior in response to one or more RLF triggering conditions, for example, based on cell quality at or prior to the time of the RLF triggering condition. A decision in WTRU may be based, for example, on whether the cell quality during a time period can be above or below a configured threshold. WTRU may trigger an RLF and initiate re-establishment when, for example, the measured quality of a serving cell DL can be above a threshold at or prior to the time the RLF triggering condition can be met. WTRU may perform one or more actions (for example, those described above) when, for example, the cell quality can be below a threshold at and / or prior to the RLF triggering condition (e.g., a specific time or an entire time period).

[0191] The time period can be constructed by the network. The time period considered in the WTRU determination may be specific to the type of RLF triggering condition. The WTRU may, for example, maintain a (e.g., continuous) measure of cell quality of a DL cell. The WTRU may determine a time period (to be used to determine, for example, whether to trigger an RLF and perform a re-establishment, or whether to perform one or more actions) based on a specific trigger (e.g., time 1 may be related to maximum RLC retransmission, time 2 may be related to a RACH problem, etc.). Examples of triggering an RLF (e.g., based on one or more conditions) can be implemented by the WTRU and / or NW in various different combinations.

[0192] The WTRU may reset RLF-related counters / timers (for example, during UL switching). For example, the WTRU may reset counters and / or timers that may be related to RLF determination, for example, during the display for switching ULs. The WTRU may reset counters during (for example, only during) a switch from a first UL type to a second UL type (for example, from RUL to SUL). The WTRU may not reset counters during a switch in the opposite direction (for example, from SUL to RUL).

[0193] A WTRU may receive a command (e.g., from the network) to switch from RUL to SUL. This command may be received, for example, by an RRC message, MAC CE, or DCI command in L1. A WTRU may reset the current values ​​of RLC retransmission counters used for RLF determination (e.g., in response to a command). For example, a WTRU may reset counters related to RACH issues (e.g., RACH preamble transmission counters). The WTRU's RRC layer may provide an indication (e.g., to the MAC layer) to reset counters, for example, upon receiving a message.

[0194] WTRU may suspend RLF-related counters / timers based on DL cell quality. For example, WTRU may avoid incrementing one or more timers / counters (e.g., those related to RLF determination) when it determines that the DL cell quality falls below a threshold. WTRU may also avoid incrementing counters / timers for UL operations performed on RUL (e.g., only RUL). The threshold may be, for example, the same threshold configured for SUL activation on initial access.

[0195] The WTRU does not need to increment the RLC retry counter, for example, when an RLC retransmission is performed while the WTRU is configured to use RUL (for example, only RUL), and / or when a retransmission occurs during a time period in which the measured DL cell quality was below a threshold.

[0196] The WTRU's RRC layer may indicate to lower layers (e.g., RLC, MAC, or PHY) when RLF-related counters or timers may be paused by the lower layer and when counter / timer increments may be enabled. The RRC layer may make decisions based, for example, on measurements of the serving cell's DL cell quality.

[0197] A WTRU, when configured with (or configurable with) a SUL, may implement one or more procedures for handling RLFs on an SCG. A WTRU may be configured with a SUL / RUL on an MCG. Although described in relation to an SCG, the examples described may also be applicable to RLFs on an MCG (for example, as well).

[0198] WTRUs may be reported in SCG failure information messages. For example, a WTRU may provide information in an SCG failure information message that can be sent to the MN to inform the MN whether the SCG failure was caused by an RLF triggering condition related to RUL or an RLF triggering condition related to SUL. The MN may, for example, inform the SN of the need to configure the PSCell UL for the WTRU or switch to SUL. The information reported in the SCG failure information message may include, for example, one or more of the following: (i) the UL carrier (e.g., RUL, SUL, or ARFCN) on which the RLF triggering condition (e.g., RLF resulting from a maximum RLC retry while on RUL) occurred; (ii) configuration information of the RUL / SUL at or before the time of the RLF (e.g., the configuration conditions of the RUL / SUL may be indicated, such as WTRU being configured on a single UL, being configured on both ULs but indicating that only one should be used, or being configured on both ULs and allowing both to be used based on scheduling); and / or (iii) one or more (e.g., sets) of measurements of the DL quality of the PSCell at or during a (e.g., configurable) time period prior to the time of the RLF triggering condition.

[0199] The time period can be defined by the network. The time period can differ for different RLF triggering conditions. The time period can be determined by the nature of the RLF triggering condition itself. In the example (for example, the maximum number of RLC retries on an SCG bearer), the time period may begin with the first RLC retransmission and end when the maximum number of RLC retransmissions can be reached. The WTRU may consist of multiple measurements taken at predefined intervals over the (e.g., entire) time period.

[0200] A partial failure of the SCG may occur based on the RUL / SUL configuration. The WTRU (for example, one or more cases) may interrupt SCG transmission, for example, depending on the RUL / SUL configuration on the SN and under one or more conditions that may trigger an SCG failure. The WTRU (for example, in other cases) may, for example, (i) initiate a switch or request to use SUL on the SN based on one or more HO procedures, or provide an indication (for example, to lower layers) to initiate such a procedure; (ii) start a timer and wait for a NW command to switch to another UL (e.g., SUL) on the SN (for example, the WTRU may, for example, suspend SCG transmission following the expiration of a timer without receiving a command from the NW); (iii) initiate an action that has generated a triggering condition on another UL (e.g., SUL) on the SN (e.g., perform a random access or retry transmission on RLC), and, if other ULs are currently configured (for example, if an RLF due to a RACH problem occurs on RUL, the WTRU may retry RACH on SUL if the WTRU is provided with SUL configuration by RRC (e.g., and only in that case)); (iv) start a timer, in the meantime, the WTRU may, in the meantime, wait for a NW command (e.g., RRC, MAC) to switch the UL to a different carrier. One or more actions (e.g., a combination of them) may be performed, such as continuing DL reception on the PSCell until a CE (or L1) is received, but delaying UL transmission on the PSCell (for example, a WTRU may interrupt SCG transmission following, for example, the expiration of a timer without receiving a command from the NW), starting a timer, and / or (v) providing an indication (e.g., to a lower layer) to reset counters that may be related to an SCG failure (e.g., the number of RLC retries, the number of PRACH transmission attempts).

[0201] The conditions for initiating an action may depend (for example, further) on ULs configured during the time of the SCG failure. A WTRU may initiate an action based on one or more conditions, for example, when the WTRU is configured with RUL but not with SUL (for example, only then).

[0202] A WTRU (when configured, for example, with transmissions using only RULs) may interrupt SCG transmissions and receptions for one or more SCG failure cases, such as (i) integrity check failures, (ii) SRB3 reconfiguration failures, and / or (iii) RLFs due to L1 problems. A WTRU may continue DL reception on the PSCell, but may delay UL transmissions on the PSCell, until it receives a UL reconfiguration or switch (e.g., to SUL) for one or more of the following: (i) an RLF due to the maximum number of RLC retries by the SCG RLC, and / or (ii) an RLF due to a random access problem on the SCG MAC. A WTRU may attempt to transmit a UL again (e.g., PRACH or RLC retransmission) (e.g., following a reconfiguration), and may reset the associated timers / counters (e.g., number of RLC retries, PRACH transmission counter).

[0203] A partial failure of the SCG may occur, for example, based on measurements on the RUL / SUL. In an example that may be used in conjunction with one or more other examples, the WTRU may initiate an action (for example, in response to measurements on the PSCell DL) (for example, rather than interrupting the SCG). For example, the WTRU may initiate one or more actions when it reaches the conditions for an SCG failure, for example, for one or more of the following: (i) an SCG failure due to maximum RLC retries in the SCG, and / or (ii) an SCG failure due to a random access problem in the SCG MAC. The conditions and actions may be combined in any combination to interrupt SCG transmission and reception.

[0204] A WTRU may transmit an SCG failure information message on the SUL. For example, a WTRU may transmit an SCG failure information message on the SUL of the SCG (for example, instead of the MN). A WTRU may transmit on the SUL of the SCG when, for example, one or more (e.g., a combination) of conditions can be satisfied (e.g., only when). The conditions may include, for example, one or more of the following: (i) the WTRU is configured using only the RUL; (ii) the WTRU is configured using both the RUL and the SUL, but is configured to transmit on only the RUL at the time of the SCG failure; (iii) the DL quality of the PSCell is below or had been below a threshold prior to the SCG failure (e.g., for a given time or time period); and / or (iv) the SCG is triggered by one or more (e.g., a set) of events (e.g., an SCG failure due to the maximum number of RLC retries and / or an SCG failure due to a random access problem in the SCG).

[0205] For example, in an additional or alternative example (which may be used in conjunction with one or more other examples), a WTRU may transmit SCG failure information as a message in a RACH procedure (for example, performed on a SUL). A WTRU may be configured with a RACH parameter (for example, only) for a SUL (for example, from broadcast signaling), and may transmit an SCG failure information message as part of MSG3 of a RACH procedure or RACH-like procedure that may be performed via a SUL.

[0206] A WTRU may select a UL (e.g., SUL or RUL) during the re-establishment procedure. For example, during the re-establishment procedure, a WTRU may select from several (e.g., two) configured ULs on which the re-establishment procedure should be initiated based on one or more criteria. For example, when a selected cell on which re-establishment has been initiated and on which the re-establishment procedure should be performed may have a configured SUL, a WTRU may select a UL (e.g., SUL or RUL) on which the re-establishment should be initiated based on one or more conditions. The conditions may include, for example, one or more of the following: (i) the cell selected during the re-establishment procedure, (ii) the WTRU speed, (iii) the WTRU battery power, (iv) the DL channel quality of the cell, (v) the previous SUL / RUL configuration provided to the WTRU by that cell when the WTRU was previously connected to that cell (e.g., whether the WTRU was configured with only one SUL, only one RUL, both and one activated, or both activated), and / or (vi) the cause of the RLF that led the WTRU to perform the re-selection.

[0207] A WTRU may use RUL when, for example, a reselection is made to a different cell than the one that triggered the RLF, and may use SUL when, for example, a reselection is made to the same cell where the RLF occurred. A WTRU may use RUL when, for example, a reselection is made to a different cell than the one that triggered the RLF, and that cell may have a DL quality above a threshold. Otherwise, a WTRU may use SUL to re-establish contact with the selected cell.

[0208] WTRU may use DL quality compared to a threshold to determine whether RUL / SUL can be used for re-establishment when the selected cell is different from the cell that triggered the RLF. When the same cell is selected, WTRU may use SUL, for example, when an RLF could have occurred while WTRU was on RUL (for example, only then).

[0209] In (for example, additional or alternative) examples, the criteria for selecting RUL / SUL when the same cell is selected may (for example, further) depend on the cause of the RLF while the WTRU was connected to the cell. For example, a WTRU may use SUL when it was configured with RUL while it was connected to the cell and / or when an RLF occurred as a result of one or more of a subset of RLF triggering conditions (for example, the maximum RLC retries being exhausted or a random access problem in an MCG MAC entity) (for example, only then).

[0210] WTRU may prioritize cells with SUL during re-selection and re-establishment. For example, WTRU may prioritize cells configured with SUL during re-selection for the re-establishment procedure. Prioritization may be performed among cells of equal quality. Prioritization may be performed for cells with quality that can differ by a maximum range (for example, some). For example, WTRU may select the cell with configured SUL when two cells with equal DL quality are measured during cell re-selection. Alternatively or additionally, WTRU may apply a quality offset (for example, improved quality) for cells that may have configured SUL (for example, during cell selection).

[0211] The network may provide system information (SI) to the WTRU. The WTRU may perform an SI request transmission for either a RUL or a SUL, for example, when both ULs are available based on the system information. The WTRU's decision criteria for selecting a RUL or SUL may depend on one or more of the following: (i) the DL quality of the cell, (ii) the WTRU speed, (iii) the WTRU battery power, (iv) the type of SI requested, (v) broadcast information by the network about the SI request procedure, (vi) the UL configured for the WTRU at the time of the request (e.g., SUL or RUL), (vii) the cell to which the WTRU is making the request, and / or (viii) the type of SI request procedure (e.g., MSG1 or MSG3-based SI request procedure).

[0212] WTRU may select UL (RUL / SUL) based on the cell's DL quality. For example, WTRU may select SUL for sending an SI request when the cell's DL quality falls below a threshold. This threshold may or may not be the same as the threshold related to selecting UL for initial access. WTRU may also select RUL when the cell's DL quality exceeds a threshold.

[0213] WTRU may perform UL selection based on WTRU speed. For example, WTRU may select SUL for sending an SI request when WTRU speed is above a threshold. Otherwise, WTRU may select RUL.

[0214] A WTRU may perform a UL selection based on the type of SI requested. For example, a WTRU may select a SUL for sending an SI request for one or more SIBs or SI messages. A WTRU may utilize a SUL for an SI request for a high-priority SIB (for example, one requesting low latency for collection or one related to a high-priority service).

[0215] A WTRU may perform UL selection based on broadcast information about the SI request procedure by the network. For example, a WTRU may select a SUL for sending an SI request based on the SI request configuration (e.g., from the NW). A WTRU may receive a PRACH preamble / resource that can be used to request a specific SI message or SIB in a broadcast minimum SI (e.g., for an MSG1-based SI request procedure). A WTRU may receive an indication of which UL (e.g., SUL or RUL) the resource is applicable to. A WTRU may perform the SI request in the corresponding UL. A WTRU may receive configurations of PRACH preamble / resources for RUL and SUL (e.g., as an addition or alternative). A WTRU may use another exemplary procedure for selecting a UL for an SI request.

[0216] UL selection-based ULs (e.g., SUL or RUL) can be configured for a WTRU, for example, at the time of the request. In the example (for example, a WTRU in RRC_INACTIVE or RRC_CONNECTED), the WTRU can select a UL for an SI request based, for example, on a configured or activated UL (e.g., SUL or RUL) for the WTRU. A WTRU (for example, in RRC_CONNECTED) can be configured using only a RUL transmission, or with both a SUL and a RUL, with only the RUL active. While in RRC_INACTIVE, a WTRU can also follow configuration / activation for an SI request (for example, that as well). This can also be coordinated to sending an SI request to the same cell that last configured the WTRU. A WTRU can use configuration to determine which UL to use when an SI request may be made to the same cell that last configured / activated the SUL / RUL. WTRU may use different criteria when a request may be made to a different cell (for example, due to mobility in RRC_INACTIVE).

[0217] Examples / conditions for handling SIs can be combined in any combination. For example, a WTRU might use a SUL to send SI requests for certain SIBs (e.g., only those) when the DL quality of a cell may fall below a threshold (e.g., only then).

[0218] Access control may be implemented for SULs. For example, the access control configuration may be specific to the UL carrier. A WTRU may be configured with a separate access control configuration for SULs, independently of the RUL carrier. A WTRU may apply a specific access control configuration related to the selected UL carrier. Such UL carrier-specific access control may enforce independent overload control based on the congestion status on each UL carrier.

[0219] A WTRU may be configured with access control configurations for a subset of access categories on the SUL (for example, compared to the RUL). A WTRU may be configured (for example, implicitly or explicitly) to prohibit transmissions related to unconfigured access categories on the SUL. A WTRU may be configured (for example, implicitly or explicitly) to reuse access control configurations from the RUL for unconfigured access categories on the SUL. One or more access control configurations from the SUL may override the baseline access control configuration from the RUL.

[0220] The WTRU may base its UL carrier selection on an access control configuration (e.g., access control that enforces selective transmission on an SUL). For example, the WTRU may be configured to select an uplink carrier from a plurality of uplink carriers based on one or more aspects related to access control. The WTRU may (e.g., based on an access control configuration) determine the type of transmission (e.g., access category) that is permitted at a particular time in a cell and / or determine the UL carrier that may be used to carry out such transmission.

[0221] In the example, the WTRU may perform UL carrier selection based on the access control configuration to route some UL transmissions to the SUL (for example, when DL path loss exceeds a threshold, but transmission via the RUL is undesirable or unnecessary). Examples of situations in which UL transmissions are routed to the SUL may include situations involving congestion in the RUL, shorter transmissions, and / or transmissions that trigger non-WTRU specific responses.

[0222] In an example involving congestion on a RUL, a WTRU may be configured to perform a transmission on a SUL when transmission on the RUL is prohibited based on the access exclusion factor configuration, and / or when an access exclusion timer associated with the RUL is running and / or when transmission on the RUL may be temporarily delayed.

[0223] In examples involving shorter transmissions, some transmissions via SUL may result in less overhead (for example, beamforming overhead on RUL may be unnecessary for shorter transmissions). WTRUs can be configured for transmissions via SUL for several access categories (e.g., RAN area updates in an inactive state). In examples, some QoS flows that generally result in shorter data bursts can be mapped to SUL carriers.

[0224] In examples involving transmissions that trigger non-WTRU-specific responses, the WTRU may be configured to make on-demand SI requests (e.g., dedicated preamble transmissions) on the SUL carrier if the DL SI transmission is broadcast.

[0225] A WTRU may be configured with separate access control parameters for SUL and RUL. Selective transmission may be enforced by enabling certain access categories on SUL (and / or blocking those access categories on RUL). For example, a WTRU may be configured with a single access control configuration, and the UL carrier to be used for a certain access category may be configured as part of the access control parameters themselves. For example, each access category may be associated with either SUL or RUL. A WTRU may determine the access category based on the characteristics of the transmission (e.g., the QoS flow ID or type of the control message transmission). A WTRU may determine the applicable UL carrier based on the access control configuration.

[0226] WTRUs can implement SUL BWP selection and switching procedures. For example, an RRC may configure a WTRU using associations between each DL BWP and / or RUL BWP and one or more SUL BWPs. This may allow the WTRU to maintain similar UL operating characteristics (e.g., BW, numerology, etc.) despite operating on different carriers.

[0227] In the example, the association procedure may be determined by the network based on one or more of the following: WTRU bandwidth operation (e.g., the numerology supported by the WTRU), WTRU RF capability (e.g., the ability to support a specific BWP on a SUL corresponding to a BWP on a RUL), power saving purposes, and / or WTRU service requirements (e.g., required bandwidth, latency, etc.).

[0228] A WTRU can receive the necessary associations between SUL BWPs and RUL BWPs through RRC signaling. The WTRU can then use such associations to enable BWP switching for both RUL and SUL using a single command from the network. For example, upon receiving a BWP switching command for RUL / SUL, the WTRU may (implicitly, for instance) switch the BWP of the other UL (SUL / RUL) to the BWP defined in the association.

[0229] The BWP association between RUL and SUL can be either a one-to-one or one-to-many association. For example, in a one-to-one association, a BWP switch in RUL from BWP1 to BWP2 may automatically result in a BWP switch in SUL to a BWP associated with BWP2. For example, in a one-to-many association, a switch in RUL to a BWP that has multiple associated BWPs in SUL may result in additional rules in WTRU for selecting SUL BWPs based on, for example, DL RSRP / RSRQ, and / or similar aspects related to WTRU bandwidth operation, power saving optimization, or numerology (which may be determined by, for example, NW).

[0230] A BWP switching command in the RUL may depend on the corresponding paired BWP in the SUL. This allows the network to initiate BWP switching in the RUL only when (for example, only when) the paired BWP in the SUL is suitable for WTRU capabilities and requirements.

[0231] In the example, when both RUL and SUL are configured for a WTRU, the RRC may configure an active BWP for the RUL and an active BWP for the SUL. Downlink Control Information (DCI)-based activation / deactivation may be supported. DCI may be an addition to activation / deactivation via dedicated RRC signaling. DCI may contain one bit of information to specify which UL the activation / deactivation command is targeting.

[0232] In the example, when one UL (for example, just one) is configured, there may be one UL BWP (for example, just one) active per cell at a time. UL carrier switching can be enabled by the WTRU receiving DCI activate / deactivate BWP commands to switch to a BWP on another UL carrier.

[0233] In the example, multiple BWPs may be active in the SUL, and the selection or switching of BWPs in the SUL may be initiated by the WTRU. The selection or switching of BWPs in the SUL may be based on DL measurements of the relevant cells.

[0234] In the example, if a WTRU is configured with both UL carriers (RUL and SUL), and the DL RSRP received by the WTRU is below a threshold, the WTRU may determine that it should be transmitted within one of the configured SUL BWPs.

[0235] In the example, the WTRU may select one of the SUL BWPs based on the measured RSRQ, (i) for example, if the received RSRP is below a threshold, the WTRU may select a SUL associated with a low-frequency BWP, and (ii) if the received RSRP is above a threshold but the received RSRQ is below another threshold, the WTRU may select a higher-frequency BWP.

[0236] WTRU may be selected based on low-frequency BWP because RSRP provides information about signal strength. For example, low RSRP may be due to path loss attenuation or interference, and BWP at lower frequencies may be more robust to fading and interference.

[0237] Since the RSSI value (in addition to the RSRP value in RSRQ calculations, for example) contains interference and noise information, a higher frequency BWP may be selected for the WTRU. For example, a low RSRQ with a high RSRP may be due to the dominance of interference, and since higher frequencies are more robust to interference, a higher frequency BWP may be more preferable for the WTRU.

[0238] Systems, methods, and means for auxiliary uplinks (SULs) in wireless systems are disclosed. For cells configured with SULs, cell compatibility criteria may be provided. A WTRU may receive paging with indication of the carrier (e.g., SUL or regular uplink (RUL)) on which some or all of the initial access should be initiated. A wireless transceiver unit (WTRU) that may be performing response-driven paging may provide beam information (e.g., explicit) about beamforming of paging messages on a non-beamforming SUL. Handover (HO) procedures (e.g., carrier selection, configuration handling, HO failure) may be provided to a WTRU having a configured SUL. A WTRU may request a change in a configured UL. A WTRU may perform a switch to a different (e.g., configured) uplink (e.g., autonomously) when one or more conditions may be met (e.g., conditional switching). A semi-persistent scheduling (SPS) resource / configuration may be relocated from a first UL to a second UL. In the presence of a SUL, duplicate and UL route selection may be provided for Radio Resource Control (RRC) messages. A WTRU may or may not trigger a Radio Link Failure (RLF) based, for example, whether conditions for an RLF relationship have occurred on a SUL / RUL, and based on the SUL / RUL configuration. Conditions may be set for pausing / resetting RLF relationship counters / timers during switching between RUL / SUL. A WTRU may inform the master node (MN) of the RUL / SUL configuration, for example, during secondary cell group (SCG) failure information reporting. For partial SCG failures that can be triggered by an SCG RLF on a RUL, procedures may be implemented (e.g., with corresponding WTRU behavior). A WTRU may select the UL carrier (e.g., SUL / RUL) on which to initiate re-establishment. In the presence of a SUL / RUL, procedures for UL selection of system information (SI) requests may be provided.

[0239] The processes and means described herein may be applied in any combination and may be applied to other wireless technologies and other services.

[0240] A WTRU can refer to the identification of a physical device, or to the identification of a user, such as an identification of a subscription relationship, such as an MSISDN or SIP URI. A WTRU can also refer to an application-based identification, such as a username that may be used for each application.

[0241] Each of the computing systems described herein may have one or more computer processors having memory or hardware configured with executable instructions for achieving the functions described herein, including determining parameters described herein and sending and receiving messages between entities (e.g., WTRUs and networks) in order to achieve the functions described herein.

[0242] The processes described above may be implemented in computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, but are not limited to built-in hard disks and removable disks, magnetic media such as magneto-optical media, and / or optical media such as CD-ROM disks and / or digital multi-purpose disks (DVDs). A software-associated processor may be used to implement radio frequency transceivers for use in WTRUs, terminals, base stations, RNCs, and / or any host computer.

Claims

1. A method performed by a Wireless Transceiver Unit (WTRU), This involves determining the compatibility of the cells. If the cell is configured with a supplemental uplink (SUL) and the WTRU supports SUL communication at the cell's frequency, the cell's suitability is determined using a first cell suitability criterion. If the cell is not configured using SUL, or if the WTRU does not support SUL communication for the cell's frequency, the cell's suitability is determined using a second cell suitability criterion. Selecting the cell based on the determined suitability of the cell, To camp on the aforementioned selected cell, Methods that include...

2. The method according to claim 1, wherein the first cell compatibility criterion utilizes a SUL offset specific to the cell, and the second cell compatibility criterion utilizes a non-SUL offset specific to the cell that is different from the SUL offset.

3. The method according to claim 1, comprising receiving the SUL offset and the non-SUL offset of the cell, wherein the first cell compatibility criterion utilizes the SUL offset and the second cell compatibility criterion utilizes the non-SUL offset.

4. Receiving system information from the aforementioned cell, The system information is determined to include SUL configuration information, Based on the reception of the SUL configuration information, it is determined that the cell is configured using the SUL, The method according to claim 1, further comprising:

5. The method according to claim 1, wherein the SUL of the cell operates at the frequency, the normal uplink (RUL) of the cell operates at a second frequency, and the WTRU determines whether it can support SUL operation at the frequency together with the RUL at the second frequency in order to determine whether it supports SUL operation in the cell.

6. The cell receives a system information block (SIB) containing information about the second cell, Determining the suitability of the second cell based on the SIB, If the second cell is configured using a supplemental uplink (SUL) and the WTRU supports SUL communication, the suitability of the second cell is determined using a third cell suitability criterion. If the second cell is not configured using SUL, or if the WTRU does not support SUL communication, the suitability of the second cell is determined using a fourth cell suitability criterion. That thing, The method according to claim 1, further comprising:

7. The method according to claim 6, wherein the SIB indicates whether the second cell supports SUL communication.

8. The method according to claim 6, wherein the SIB comprises an adjacent cell list with indications of cell identification (ID) and SUL frequency of cells that support SUL.

9. The method according to claim 6, wherein the third cell compatibility criterion utilizes a second SUL offset specific to the second cell, and the fourth cell compatibility criterion utilizes a second non-SUL offset specific to the second cell.

10. Based on the determined suitability of the second cell, the second cell is selected, To camp on to the second cell and The method according to claim 6, further comprising:

11. A wireless transceiver unit (WTRU), If a cell is configured with a supplemental uplink (SUL) and the WTRU supports SUL communication at the cell's frequency, the suitability of the cell is determined using a first cell suitability criterion. If the cell is not configured using SUL, or if the WTRU does not support SUL communication for the cell's frequency, the suitability of the cell is determined using a second cell suitability criterion. Based on the determined suitability of the cell, select the cell, Camp on to the selected cell. A WTRU equipped with a processor configured as such.

12. The WTRU according to claim 11, wherein the first cell compatibility criterion utilizes a SUL offset specific to the cell, and the second cell compatibility criterion utilizes a non-SUL offset different from the SUL offset specific to the cell.

13. The WTRU according to claim 11, wherein the processor is configured to receive the SUL offset and the non-SUL offset of the cell, the first cell compatibility criterion utilizes the SUL offset, and the second cell compatibility criterion utilizes the non-SUL offset.

14. The aforementioned processor, System information is received from the aforementioned cell, The system information is determined to include SUL configuration information, Based on the reception of the SUL configuration information, it is determined that the cell is configured using the SUL. The WTRU according to claim 11, further configured as follows.

15. The aforementioned processor, System information is received from the aforementioned cell, It is determined that the aforementioned system information does not include SUL configuration information. The WTRU according to claim 11, further configured as follows.

16. The aforementioned processor, From the aforementioned cell, a system information block (SIB) containing information about the second cell is received. The suitability of the second cell is determined based on the SIB. It is further configured in this way, If the second cell is configured with a supplemental uplink (SUL) and the WTRU supports SUL communication, the processor is configured to determine the suitability of the second cell using a third cell suitability criterion. The WTRU according to claim 11, wherein if the second cell is not configured using SUL or the WTRU does not support SUL communication, the processor is configured to determine the suitability of the second cell using a fourth cell suitability criterion.

17. The WTRU according to claim 16, wherein the SIB indicates whether the second cell supports SUL communication.

18. The WTRU according to claim 16, wherein the SIB comprises an adjacent cell list with indications of cell identification (ID) and SUL frequency of cells that support SUL.

19. The WTRU according to claim 16, wherein the third cell compatibility criterion utilizes a second SUL offset specific to the second cell, and the fourth cell compatibility criterion utilizes a second non-SUL offset specific to the second cell.

20. The aforementioned processor, Based on the determined suitability of the second cell, the second cell is selected. Camp on to the second cell The WTRU according to claim 16, further configured as follows.

21. A wireless transceiver unit (WTRU), The system receives a first handover (HO) command to a first cell associated with a first supplemental uplink (SUL) and a first regular uplink (RUL), the first HO command including an explicit indication that the first SUL or the first RUL must be used for random access to complete the first HO, Execute the HO to the first cell in accordance with the first HO command, Upon receiving a second handover (HO) command to a second cell associated with a second SUL and a second RUL, the processor determines whether to use the second SUL or the second RUL for random access to complete the HO based on the downlink reference signal received power (DL-RSRP) of the SUL. If the DL-RSRP is below a threshold, the processor is configured to select the SUL as the UL carrier for the HO. If the DL-RSRP is equal to or greater than the threshold, the processor is configured to select the RUL as the UL carrier for the HO. The HO to the second cell is executed according to the second HO command. A WTRU comprising the processor configured as described above.

22. A method performed by a Wireless Transceiver Unit (WTRU), Receiving the first handover (HO) command, Determining that the first HO command includes an explicit indication of one uplink (UL) carrier of HO, Selecting a UL carrier for the first HO command based on whether a random access channel (RACH) resource for a supplemental uplink (SUL) or regular uplink (RUL) is provided for the first HO command, Performing an HO to the selected UL carrier displayed by the first HO over command, Receiving the second HO command, Determining that the second HO command includes configurations for both SUL and RUL within the second HO command, The selection of a UL carrier for the second HO command based on whether the downlink reference signal received power (DL-RSRP) of the SUL is below a threshold, wherein if the DL-RSRP of the SUL is below a threshold, the SUL is selected as the UL carrier for the second HO, and if the DL-RSRP of the SUL is equal to or greater than the threshold, the RUL is selected as the UL carrier for the second HO. Execute the HO to the selected UL carrier displayed by the second HO command. Methods that include...

Images