Transmission Processing for PCI Satellite Switching

Abstract

A wireless transmit / receive unit (WTRU) may comprise a processor. The processor may be configured to receive configuration information (e.g., via broadcast) indicating a time at which same PCI satellite switching may occur. In one or more examples, the WTRU may be able to transmit assistance information prior to same PCI satellite switching. The assistance information may include, for example, a resynchronization duration, an ability for a synchronization procedure, and / or a time indication for resuming TX and / or RX. The WTRU may be able to receive configuration information for satellite resynchronization. The WTRU may be able to perform same PCI satellite switching to a second satellite based on, for example, the configuration information indicating the time of same PCI satellite switching. When performing same PCI satellite switching, the WTRU may be able to start a resynchronization gap, interrupt UL TX and / or DL RX, and / or perform a resynchronization procedure.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims the benefit of U.S. Provisional Patent Application No. 63 / 456,866, filed Apr. 4, 2023, the entire content of which is incorporated herein by reference.

Background Art

[0002] A WTRU may be configured for use in a non - terrestrial network (NTN). The non - terrestrial network (NTN) can facilitate the deployment of wireless networks in areas where terrestrial - based antennas may be impractical and / or undesirable. For example, terrestrial - based antennas may be impractical due to geography and / or cost. When combined with a terrestrial network, the NTN can provide ubiquitous 5G network coverage. Some exemplary NTN deployments can support basic conversations and text around the world. NTN deployments, combined with the proliferation of next - generation low - earth - orbit satellites, can enable further services (e.g., web browsing).

[0003] The NTN can include an air or space platform that can transmit signals from a terrestrial - based gNB to a WTRU and vice versa via a gateway (GW). Exemplary NTN deployments can support omnidirectional antennas and power class 3 WTRUs with linear polarization, or small aperture antennas (VSAT) terminals with directional antennas and circular polarization. Exemplary NTNs can provide support for LTE - based narrowband IoT (NB - IoT) and eMTC - type devices. In examples, regardless of the device type, NTN WTRUs can be GNSS - enabled.

Summary of the Invention

[0004] A wireless transmit / receive unit (WTRU) can comprise a processor configured to receive configuration information indicating a time for same physical cell identifier (PCI) satellite handover from a first satellite to a second satellite. The configuration information can include an indication of a start time and an end time of the same PCI satellite handover from the first satellite to the second satellite. The processor can be further configured to receive a configuration for satellite resynchronization with the second satellite. The processor can be further configured to perform the same PCI satellite handover to the second satellite based on the configuration information indicating the time of the same PCI satellite handover.

[0005] The configuration information can be received via broadcast signaling. The processor can be further configured to start a resynchronization gap in response to the same PCI satellite handover. The processor can be further configured to interrupt an uplink transmission with the first satellite in response to the same PCI satellite handover. The processor can be further configured to perform one or more resynchronization procedures in response to the same PCI satellite handover. The processor can be further configured to transmit a resynchronization success indication in response to successful resynchronization to the second satellite.

[0006] One or more resynchronization procedures can include timing advance calculation, Doppler compensation, power control procedures, and / or measurement procedures. In response to the same PCI satellite handover, the processor can be further configured to start a resynchronization gap, interrupt uplink transmission and downlink reception, and perform one or more resynchronization procedures. The resynchronization procedures can include timing advance calculation, Doppler compensation, power control procedures, and / or measurement procedures. The configuration for satellite resynchronization can include resynchronization gap configuration, conditions for declaring resynchronization failure, and / or resources for indicating successful resynchronization to the second satellite.

[0007] The processor may be further configured to transmit assistance information related to resynchronization time to assist in the measurement gap configuration. The assistance information may include a resynchronization duration, an indication that the WTRU can perform a synchronization procedure before the same PCI satellite handover, and / or an indication of the time at which the WTRU can resume communication with a second satellite after the same PCI satellite handover.

Brief Description of the Drawings

[0008]

Figure 1A

Figure 1B

Figure 1C

Figure 1D

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

DETAILED DESCRIPTION OF THE INVENTION

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

[0010] As shown in FIG. 1A, communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RANs 104 / 113, CNs 106 / 115, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d, which may each be referred to as a “station” and / or “STA,” may be configured to transmit and / or receive wireless signals and may be a user equipment (UE), a mobile station, a fixed subscriber unit or a mobile subscriber unit, a subscriber-based unit, a wireless call, a cellular phone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable head-mounted display (HMD), a vehicle, a drone, a medical device and application (e.g., for remote surgery), an industrial device and application (e.g., robots and / or other wireless devices operating in an industrial and / or automated processing chain context), a home appliance device, a device operating in a commercial wireless network and / or an industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU. Further, any description in this specification that refers to a UE may equally apply to a WTRU (or vice versa). For example, a WTRU may be configured to perform any of the processes or procedures described herein as being performed by a UE (or vice versa).

[0011] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a, 114b may be any type of device configured to wirelessly interface with at least one of WTRUs 102a, 102b, 102c, 102d to facilitate access to one or more communication networks such as CN106 / 115, Internet 110, and / or other network 112. By way of example, base stations 114a, 114b may be a base transceiver station (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, 114b are each shown as a single element, it will be understood that base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0012] Base station 114a may be part of RAN 104 / 113 and may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals at one or more carrier frequencies, which may be referred to as a cell (not shown). These frequencies may be licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide wireless service coverage to a specific geographic area that may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Thus, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver per sector of the cell. In one embodiment, 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 transmit and / or receive signals in a desired spatial direction.

[0013] Base stations 114a, 114b may communicate with one or more of WTRUs 102a, 102b, 102c, 102d via 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.). Air interface 116 may be established using any suitable radio access technology (RAT).

[0014] More specifically, as described above, the communication system 100 may be a multiple access system, and may use one or more channel access methods such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base stations 114a within RAN104 / 113, and the WTRUs 102a, 102b, 102c may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use wideband CDMA (WCDMA) to establish the air interfaces 115 / 116 / 117. WCDMA may include communication protocols such as High-Speed Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High-Speed Downlink Packet Access (HSDPA) and / or High-Speed UL Packet Access (HSUPA).

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

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

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

[0018] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c may implement wireless 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), IS-95, IS-856, Global System for Mobile communications (GSM), Enhanced Data rates for GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

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

[0020] RAN 104 / 113 may communicate with CN 106 / 115, which may be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 may provide call control, billing services, mobile location information services, prepaid calls, internet connectivity, video distribution, etc., and / or may implement high-level security functions such as user authentication. Although not shown in Figure 1A, it will be understood that RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs using the same or a different radio access technology (RAT) as RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may utilize New Radio (NR) radio technology, CN 106 / 115 may also communicate with another RAN (not shown) using GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0021] CN106 / 115 may also serve as a gateway for WTRU102a, 102b, 102c, 102d to access the PSTN108, the Internet 110, and / or other networks 112. The PSTN108 may include a circuit-switched telephone network that provides a plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices, where these networks and devices use a common communication protocol such as the transmission control protocol (TCP), the user datagram protocol (UDP), and / or the internet protocol (IP) of the TCP / IP internet protocol suite. The network 112 may include a wired communication network and / or a wireless communication network that is owned and / or operated by another service provider. For example, the network 112 may include another CN connected to one or more RANs that may use the same RAT or a different RAT as the RAN104 / 113.

[0022] Some or all of the WTRU102a, 102b, 102c, 102d in the communication system 100 may include a multimode function (e.g., the WTRU102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links). For example, the WTRU102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ a cellular-based wireless technology and a base station 114b that may employ IEEE802 wireless technology.

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

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

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

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

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

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

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

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

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

[0032] WTRU102 may include a full-duplex radio in which some or all of the transmission and reception of signals associated with a particular subframe (e.g., for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be parallel and / or simultaneous. The full-duplex radio may include an interference management unit 139 for reducing and / or substantially eliminating self-interference via either hardware (e.g., choke) or signal processing via a processor (e.g., via a separate processor (not shown) or via processor 118). In one embodiment, the WRTU102 may include a half-duplex radio for the transmission and reception of some or all of the signals (e.g., associated with a particular subframe for either UL (e.g., for transmission) or downlink (e.g., for reception)).

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

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

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

[0036] CN 106 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 foregoing elements is shown as part of CN 106, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0037] The MME 162 can be connected to each of the eNodeBs 162a, 162b, 162c in the RAN 104 via the S1 interface and can function as a control node. For example, the MME 162 can authenticate users of the WTRUs 102a, 102b, 102c, activate / deactivate bearers, select a specific serving gateway during the initial attach of the WTRUs 102a, 102b, 102c, etc. The MME 162 can provide control plane functions for switching between the RAN 104 and other RANs (not shown) that employ other radio technologies such as GSM and / or WCDMA.

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

[0039] The SGW 164 can be connected to the PGW 166, and the PGW 166 can provide access to a packet switched network such as the Internet 110 to the WTRUs 102a, 102b, 102c to facilitate communication between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0040] CN106 can facilitate communication with other networks. For example, CN106 can provide access to a circuit-switched network such as PSTN108 to WTRU102a, 102b, 102c in order to facilitate communication between the WTRU102a, 102b, 102c and a conventional landline communication device. For example, CN106 may include or communicate with an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that functions as an interface between CN106 and PSTN108. In addition, CN106 can provide access to another network 112 to the WTRU102a, 102b, 102c, and the other network 112 may include other wired and / or wireless networks owned and / or operated by other service providers.

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

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

[0043] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) of the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS), or another type of wired / wireless network that carries traffic entering and / or exiting the BSS. Traffic destined for an STA that originates outside the BSS may reach and be delivered to the STA through the AP. Traffic originating from an STA to a destination outside the BSS may be sent to the AP to be delivered to their respective destinations. Traffic between STAs within the BSS may be sent through the AP, for example, where the source STA may send the traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic may be sent between the source STA and the destination STA (e.g., directly between them) using direct link setup (DLS). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunneled DLS (TDLS). A WLAN using independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (e.g., all of the STAs) may communicate directly with each other. The IBSS mode of communication may be referred to herein as the "ad hoc" communication mode.

[0044] When using the 802.11ac infrastructure operation mode or a similar operation mode, the 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 wide bandwidth) or a width dynamically set via signaling. The primary channel may be the operating channel of the BSS, but can be used by the STA to establish a connection with the AP. In certain representative embodiments, for example, in an 802.11 system, Carrier Sense Multiple Access with Collision Avoidance (CSMA / CA) may be implemented. In the case of CSMA / CA, STAs including the AP (e.g., all STAs) may sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, the particular STA may back off. Only one STA (e.g., only one station) may transmit at any given time in a given BSS.

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

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

[0047] The sub-1 GHz operating mode is supported by 802.11af and 802.11ah. The channel operating bandwidth and carriers are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports bandwidths of 5 MHz, 10 MHz, and 20 MHz in the TV White Space (TVWS) spectrum, and 802.11ah supports bandwidths of 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz using the non-TVWS spectrum. According to an exemplary embodiment, 802.11ah may support meter type control / machine type communication, such as MTC devices within a macro communication range area. The MTC device may have limited capabilities, including certain capabilities, such as support for a certain and / or limited bandwidth (e.g., support only for these). The MTC device may include a battery having a battery life above a threshold (e.g., to maintain a very long battery life).

[0048] A WLAN system that supports multiple channels and channel bandwidths such as 802.11n, 802.11ac, 802.11af, and 802.11ah includes channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or restricted by an STA from among all STAs operating in a BSS that supports a minimum bandwidth operation mode. In an example of 802.11ah, the primary channel is 1 MHz wide for an STA (e.g., an MTC type device) that supports the 1 MHz mode (e.g., supports only this) even when the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operation modes. Carrier sensing and / or Network Allocation Vector (NAV) setting may depend on the status of the primary channel. For example, due to an STA transmitting to an AP (supporting only the 1 MHz operation mode), if the primary channel is busy, even if most of the frequency band remains idle and may be available, the entire available frequency band may be considered busy.

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

[0050] Figure 1D is a system diagram illustrating RAN113 and CN115 according to one embodiment. As described above, RAN113 may use NR radio technology to communicate with WTRUs 102a, 102b, 102c via air interface 116. RAN113 may also communicate with CN115.

[0051] RAN 113 may include gNBs 180a, 180b, and 180c, but it should be understood that RAN 113 may include any number of gNBs while remaining consistent with one embodiment. Each of gNBs 180a, 180b, and 180c may include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 108b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Thus, gNB 180a may transmit and / or receive radio signals to / from WTRU 102a, for example, using multiple antennas. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a may transmit a plurality of component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Coordinated Multi-Point (CoMP) technology. For example, WTRU 102a may receive coordinated transmission from gNB 180a and gNB 180b (and / or gNB 180c).

[0052] WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, the OFDM symbol interval and / or the OFDM sub-carrier interval may vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRU102a, 102b, and 102c may communicate with gNB180a, 180b, and 180c using sub-frames or transmission time intervals (TTIs) of various or scalable lengths (e.g., including various numbers of OFDM symbols and / or having absolute times of various lengths).

[0053] gNBs 180a, 180b, and 180c may be configured to communicate with WTRUs 102a, 102b, and 102c in a stand-alone configuration and / or a non-stand-alone configuration. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c without accessing other RANs (e.g., eNodeBs 160a, 160b, 160c, etc.). In a stand-alone configuration, WTRUs 102a, 102b, and 102c may utilize one or more of gNBs 180a, 180b, and 180c as mobility anchor points. In a stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with gNBs 180a, 180b, and 180c using signals in an unlicensed band. In a non-stand-alone configuration, WTRUs 102a, 102b, and 102c may communicate with and connect to gNBs 180a, 180b, and 180c while also communicating with and connecting to another RAN such as eNodeBs 160a, 160b, and 160c. For example, WTRUs 102a, 102b, and 102c may implement a DC principle for communicating with one or more gNBs 180a, 180b, and 180c and one or more eNodeBs 160a, 160b, and 160c substantially simultaneously. In a non-stand-alone configuration, eNodeBs 160a, 160b, and 160c may function as mobility anchors for WTRUs 102a, 102b, and 102c, and gNBs 180a, 180b, and 180c may provide additional coverage and / or throughput for servicing WTRUs 102a, 102b, and 102c.

[0054] Each of gNBs 180a, 180b, and 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decision-making, handover decision-making, 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 (UPFs) 184a, 184b, routing of control plane information to access and mobility management functions (AMFs) 182a, 182b, etc. As shown in FIG. 1D, gNBs 180a, 180b, and 180c may communicate with each other via the Xn interface.

[0055] As shown in FIG. 1D, CN 115 may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one session management function (SMF) 183a, 183b, and optionally data networks (DNs) 185a, 185b. Although each of the foregoing elements is shown as part of CN 115, it will be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0056] AMF 182a and 182b can be connected to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can function as control nodes. For example, AMF 182a and 182b may perform roles such as authentication of users of WTRUs 102a, 102b, and 102c, support for network slicing (e.g., handling of different PDU sessions with different requirements), selection of specific SMFs 183a and 183b, management of the registration area, termination of NAS signaling, and mobility management. Network slices can be used by AMF 182a and 182b to customize the CN support for WTRUs 102a, 102b, and 102c based on the type of services being utilized by WTRUs 102a, 102b, and 102c. For example, different network slices may be established for different use cases such as services that rely on ultra-reliable low latency (URLLC) access, services that rely on enhanced massive mobile broadband (eMBB) access, and services for machine type communication (MTC) access. AMF 162 may provide control plane functions for switching between RAN 113 and other RANs (not shown) that use other radio technologies such as non-3GPP access technologies like LTE, LTE-A, LTE-A Pro, and / or WiFi.

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

[0058] UPF184a and 184b can be connected to one or more of gNB180a, 180b, and 180c within RAN113 via the N3 interface, thereby providing 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-corresponding 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.

[0059] 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 functions as an interface between CN115 and PSTN108. Further, CN115 may provide access to other network 112 for WTRU102a, 102b, 102c, and other network 112 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 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.

[0060] With reference to FIGS. 1A - 1D and the corresponding descriptions thereof, one or more of the functions described herein with respect to one or more of WTRU102a - d, base stations 114a and b, eNode - Bs 160a - c, MME162, SGW164, PGW166, gNBs 180a - c, AMFs 182a - ab, UPFs 184a and b, SMFs 183a and b, DNs 185a and b, and / or any other device 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 simulate network and / or WTRU functionality.

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

[0062] One or more emulation devices can perform one or more functions including all while not being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device can be utilized in a test scenario in a test laboratory and / or in a wired and / or wireless communication network that is not deployed (e.g., for testing) to implement tests of one or more components. One or more emulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit (which can include one or more antennas) can be used by the emulation device to transmit and / or receive data.

[0063] In this specification, among others, the following abbreviations and acronyms are used: Acknowledgement (ACK), Block Error Rate (BLER), Bandwidth Part (BWP), Channel Access Priority (CAP), Channel access priority class (CAPC), Clear Channel Assessment (CCA), Control Channel Element (CCE), Control Element (CE), configured grant or cell group (CG), Cyclic Prefix (CP), Conventional OFDM (relying on cyclic prefix) (CP - OFDM), Channel Quality Indicator (CQI), Cyclic Redundancy Check (CRC), Channel State Information (CSI), Contention Window (CW), Contention Window Size (CWS), Channel Occupancy (CO), Downlink Assignment Index (DAI), Downlink Control Information (DCI), Downlink feedback information (DFI), Dynamic grant (DG), Downlink (DL), Demodulation Reference Signal (DM - RS), Data Radio Bearer (DRB), enhanced Licensed AssistedAccess, eLAA (Enhanced Licensed Assisted Access), Further enhanced Licensed Assisted Access (FeLAA), Hybrid Automatic Repeat Request (HARQ), License Assisted Access (LAA), Listen-Before-Talk (LBT), Long Term Evolution (LTE) since 3GPP LTE R8, Line of sight probability indication (LOSPI), Negative ACK (NACK), Non-Terrestrial Network (NTN), Modulation and Coding Scheme (MCS), Multiple Input Multiple Output (MIMO), New Radio (NR), Orthogonal Frequency-Division Multiplexing (OFDM), Physical Layer (PHY), Process ID (PID), Paging Occasion (PO), Physical Random Access Channel (PRACH), Primary Synchronization Signal (PSS), Random Access (or procedure) (RA), Random Access Channel (RACH), Random Access Response (RAR), Radio access network Central Unit (RCU), Radio Front end (RF), Radio Link Failure (RLF), Radio Link Monitoring (RLM), Radio Network Identifier (RNTI), RACH Occasion (RO), Radio Resource Control (Radio ResourceControl, RRC), Radio Resource Management (RRM), Reference Signal (RS), Reference Signal Received Power (RSRP), Received Signal Strength Indicator (RSSI), Service Data Unit (SDU), Sounding Reference Signal (SRS), Synchronization Signal (SS), Secondary Synchronization Signal (SSS), Switching Gap (SWG) (in a self - contained sub - frame), Semi - Persistent Scheduling (SPS), Supplemental Uplink (SUL), Transport Block (TB), Transport Block Size (TBS), Transmission / Reception Point (TRP), Time - sensitive communications (TSC), Time - sensitive networking (TSN), Uplink (UL), Ultra - Reliable and Low Latency Communications (URLLC), Wide Bandwidth Part (WBWP).

[0064] A WTRU may support synchronization during same Physical Cell Identity (PCI) satellite handover. In one or more cases, the WTRU may receive assistance information regarding same PCI satellite handover (e.g., via broadcast signaling). This information may include timing information and / or incoming satellite position information at the time when the same PCI satellite handover occurs. The WTRU may pre - calculate a timing advance based on the future position of the incoming satellite at the time of same PCI satellite handover. The WTRU may pre - report a future TA value with the indicated offset before the satellite handover. The WTRU may reset the L3 measurement window and apply a measurement configuration at the time of satellite handover. The measurement configuration may be pre - configured. The pre - configured measurement configuration may include, for example, but is not limited to, a higher density of measurement objects. The WTRU may apply the pre - configured measurement configuration and filter coefficients to evaluate the new channel state.

[0065] The WTRU may provide capabilities and / or assistance information regarding resynchronization time, for example, to support gap measurement configurations. In an example, the WTRU may ignore pre - configured scheduling (e.g., CG, periodic SRS, etc.) during the resynchronization time.

[0066] The WTRU may scale the power for the initial UL transmission to the incoming satellite. The WTRU may scale the power for the initial UL transmission based on the difference in distance between the WTRU and the previous satellite and the incoming satellite. In one or more cases, the power scaling may be enabled based on a configuration / indication in the System Information Block (SIB). Alternatively or additionally, the power scaling may be based on the probability of line - of - sight (e.g., LOSPI%>X).

[0067] The WTRU can measure a reference signal from an incoming satellite and determine how to reorient the spatial filter when a new satellite takes over coverage. For example, the WTRU can measure a reference signal from an incoming satellite, such as one or more SSB / CSI-RS from an adjacent cell. In one or more cases, the WTRU receives an indication / configuration of a reference signal that is QCL with a second reference signal in a second period (e.g., after handover) where a first period (e.g., before handover) to link measurements between cells transmitted from the satellite.

[0068] In one or more cases, the WTRU can optionally send an ACK to the incoming satellite (e.g., via SR, via pre-provisioned resources, using the earliest available CG resources, etc.) to confirm that synchronization is regained. For example, the WTRU can optionally send an ACK via one or more of SR, pre-provisioned resources, using the earliest available CG resources, etc.

[0069] The WTRU can be configured for use in a non-terrestrial network (NTN). The non-terrestrial network (NTN) can facilitate the deployment of a wireless network in areas where terrestrial-based antennas may be impractical and / or undesirable. For example, terrestrial-based antennas may be impractical due to geography and / or cost. Combined with a terrestrial network, the NTN can provide ubiquitous 5G network coverage. Some exemplary NTN deployments can support basic conversations and text around the world. NTN deployments, combined with the explosion of next-generation low-earth orbit satellites, can enable additional services (e.g., web browsing).

[0070] NTN can include an aerial or space platform that can transmit signals from a ground-based gNB to a WTRU and vice versa via a gateway (GW). Exemplary NTN deployments can support an omnidirectional antenna and a power class 3 WTRU with linear polarization, or a small aperture antenna (VSAT) terminal with a directional antenna and circular polarization. Exemplary NTN can provide support for LTE-based narrowband IoT (NB-IoT) and eMTC type devices. In an example, regardless of the device type, the NTN WTRU can be GNSS-capable.

[0071] Aerial or space platforms can be classified with respect to orbit. In some implementations, low Earth orbit (LEO) satellites can operate within an altitude range of 300 - 1500 km, and geostationary orbit (GEO) satellites can operate within an altitude range of 35 - 786 km. Additional platform classifications can also be or alternatively be supported. For example, medium Earth orbit (MEO) satellites that can operate within an altitude range of 7000 - 25000 km, and high altitude platform station (HAPS) that can operate within an altitude range of 8 - 50 km can be supported. Satellite platforms can be further classified as having a "transparent" or "regenerative" payload. A transparent satellite payload can implement frequency conversion and RF amplification in both the UL and DL. In some implementations, multiple transparent satellites can be connected to one ground-based gNB. In some examples, a regenerative satellite payload can utilize either a complete gNB or gNB DU mounted on the satellite. The regenerative payload can perform digital processing on signals, including, for example, demodulation, decoding, re-encoding, remodulation, and / or filtering.

[0072] FIG. 2 shows an exemplary interface in the non-terrestrial network 200. The following wireless interfaces can be defined in NTN. For example, feeder links 202a, 202b can be wireless links between GW 210 and satellites 208a, 208b. Service link 206 can be a wireless link between satellites 208a, 208b and WTRU 212. In some implementations, the inter-satellite link (ISL) 204 can be a transport link between satellite 208a and satellite 208b. ISL 204 can be supported by a regenerative payload and can be a 3GPP wireless or proprietary optical interface.

[0073] Various communication interfaces (e.g., 3GPP) can be used for each wireless link, e.g., depending on the satellite payload configuration. For example, in a transparent payload, the NR-Uu wireless interface can be used for both service link 206 and feeder links 202a, 202b. In the example, for a regenerative payload, the NR-Uu interface can be used for service link 206 and the satellite radio interface (SRI) can be used for feeder links 202a, 202b. In some implementations, the ISL may not be utilized. In the example, there can be a UP / CP protocol stack for a transparent payload configuration.

[0074] The NTN satellite can support multiple cells, and each cell includes one or more satellite beams. The satellite beam can cover a footprint on the Earth (such as a terrestrial cell). The satellite beam can have a variable diameter (e.g., 100 - 1000 km in diameter for LEO deployment and 200 - 3500 km in diameter for GEO deployment). The beam footprint in GEO deployment can remain fixed relative to the Earth. In the case of LEO deployment, the area covered by the beam / cell can change over time due to the movement of the satellite. In one example, beam movement can be classified as "Earth movement" where the LEO beam can move continuously across the Earth. In another example, beam movement can be classified as "quasi - earth fixed", where the beam can be steered to cover a fixed position until a new cell overtakes the coverage area in discrete and coordinated changes.

[0075] The round - trip time (RTT) and / or the maximum differential delay can be larger than those of terrestrial systems, for example, based on the altitude of the NTN platform and / or the beam diameter. In an exemplary transparent NTN deployment, the RTT can range from 25.77 ms (e.g., LEO at 600 km altitude) to 541.46 ms (GEO), and the maximum differential delay can range from 3.12 ms to 10.3 ms. In an example, the RTT of the regenerated payload can be approximately half of the RTT of the transparent payload. The RTT of the regenerated payload can be approximately half of the RTT of the transparent payload because, for example, the transparent configuration can consider both the service link and the feeder link, while the RTT of the regenerated payload can consider only the service link. To minimize the impact on existing NR systems (e.g., to avoid preamble ambiguity or to properly adjust the timing of the receive window), the WTRU can perform timing pre - compensation before initial access.

[0076] In one or more cases, the WTRU may be configured with user plane extension. The pre-compensation procedure may instruct the WTRU to obtain the position of the WTRU via GNSS and obtain the feeder link (or common) delay and satellite position via satellite ephemeris data. The satellite ephemeris data may be broadcast periodically in the system information. In an example, the satellite ephemeris data may include the speed, direction, and / or velocity of the satellite. The WTRU may estimate the distance (and thus the delay) from the satellite. The WTRU may add a feeder link delay component to obtain the complete WTRU-gNB RTT. The complete WTRU-gNB RTT may be used to offset timers, receive windows, or timing relationships, including the ra-ResponseWindow, msgb-ReponseWindow, and ra-ContentionResolutionTimer. The network may perform frequency compensation.

[0077] The WTRU may calculate a WTRU-specific TA (and thus the WTRU-gNB RTT), and an exemplary implementation may include procedures for reporting the TA estimate to the network via a new MAC CE. The timing advance report (TAR) may be triggered in some examples when one or more of the following events occur. The TAR may be triggered in response to an indication from a higher layer to trigger a timing advance report. If the WTRU has not previously reported a TA value to the current serving cell, the TAR may be triggered based on the configuration of offsetThresholdTA by the higher layer. In another example, the TAR may be triggered if the configured variation between the current information regarding timing advance and the last reported information regarding timing advance is greater than or equal to offsetThresholdTA.

[0078] In one or more cases, the WTRU may be configured with HARQ and / or DRX enhancements. The WTRU may be semi-statically configured via RRC to apply a particular HARQ behavior to a set of HARQ process IDs. This semi-static configuration may be configured per serving cell. Further, the semi-static configuration may optionally be configured for both UL and DL HARQ processes via one or both of the optional configurations downlinkHARQ-feedbackDisabled and uplinkHARQ-Mode. With respect to downlinkHARQ-feedbackDisabled, the WTRU can be configured per HARQ process ID to indicate whether DL HARQ feedback is enabled or disabled. With respect to uplinkHARQ-Mode, the WTRU can be configured per HARQ process ID to indicate whether the UL HARQ process uses HARQModeA or HARQmodeB. In an example, HARQmodeA may be applicable to transmissions where UL HARQ retransmissions are enabled, and HARQmodeB may be applicable to transmissions where UL HARQ retransmissions are disabled or transmissions using blind UL retransmissions.

[0079] The WTRU can adapt the DRX timer based on the configured HARQ characteristics of the HARQ process. DRX can be adapted for both UL and / or DL to account for additional propagation delays (e.g., when HARQ feedback is enabled) and / or to enable additional WTRU power savings (e.g., when HARQ feedback is disabled). The WTRU can adapt its operation based on one or more of the following examples. The WTRU can adapt the DRX timer for DL based on one or more of the following examples. For example, when downlinkHARQ-FeedbackDisabled is configured for this serving cell, upon DL reception, the WTRU can extend the length of the DL HARQ RTT timer by the WTRU-gNB RTT (e.g., propagation delay) when HARQ feedback is enabled for the HARQ process. When downlinkHARQ-FeedbackDisabled is configured for this serving cell, upon DL reception, the WTRU does not have to start the drx-RetransmissionTimerDL to enable additional power savings when HARQ feedback is disabled for the HARQ process. For DL, when downlinkHARQ-FeedbackDisabled is configured for this serving cell, upon DL reception, the WTRU can apply legacy behavior (e.g., start the drx-RetransmissionTimerDL after the expiration of the drx-HARQ-RTT-TimerDL) when downlinkHARQ-FeedbackDisabled is not configured.

[0080] The WTRU can adapt the DRX timer for the UL with respect to the DL based on one or more of the following examples. For example, when the uplink HARQ - Mode is configured for this serving cell, at UL transmission, if the HARQ process is configured as HARQ Mode A, the WTRU can extend the length of the DL HARQ RTT timer by the WTRU - gNB RTT (i.e., the propagation delay). When the uplink HARQ mode is configured for this serving cell, at UL transmission, if the HARQ process is configured as HARQ Mode B, the WTRU may not start the drx - RetransmissionTimerDL to enable additional power savings. When the uplink HARQ mode is configured for this serving cell, at UL transmission, if the uplink HARQ mode is not configured, the WTRU can apply legacy behavior (e.g., start the drx - RetransmissionTimerUL after the expiration of the drx - HARQ - RTT - TimerUL).

[0081] In one or more cases, the WTRU can be configured with LCP extensions based on HARQ behavior. The WTRU can be configured to apply LCP restrictions based on the UL HARQ mode configured for the HARQ process ID to which the UL grant is assigned. In one or more examples, the WTRU behavior can be specified based on two optional RRC configured uplink HARQ modes and allowed HARQ modes. The uplink HARQ mode can configure the HARQ process ID as, for example, either HARQ Mode A or HARQ Mode B. The allowed HARQ - Mode can be configured per logical channel and sets the allowed HARQ mode of the HARQ processes mapped to this logical channel.

[0082] Upon receiving a new UL grant, the WTRU can determine whether the allowed HARQ mode is configured for this LCH and / or whether the HARQ mode is configured for the HARQ process of the UL grant. If both are configured and the LCH is permitted to be mapped to the HARQ mode, the restrictions may be met and data from this logical channel may be mapped to the UL grant. If either the uplink HARQ mode or the allowed HARQ mode is not configured, the WTRU can map this logical channel to any HARQ process.

[0083] In one or more cases, the WTRU may be configured with control plane enhancements. In an example, the enhancements to RRC_CONNECTED adapt mobility and / or measurement procedures to non-terrestrial environments. The modifications to mobility may include additional execution conditions for conditional handovers such as event A4, and time / position-based conditions. The position-based event may be defined by condEventD1. The position-based event may be met when the distance between the WTRU and a first reference position (e.g., within the serving cell) exceeds a threshold and a second reference position (e.g., within an adjacent cell) is below the threshold. The time-based event may be defined by condEventT1. The time-based event may be met when conditional handover execution occurs, for example, between T1 and T2, where T2 = T1 + duration.

[0084] In an exemplary NTN implementation, both time-based trigger conditions and location-based trigger conditions can be configured simultaneously in measurement conditions (e.g., A4). Other modifications can be applied to the measurement and can include one or more of the following: location-based measurement reports, multiple synchronization signal block (SSB)-based measurement timing configurations (SMTCs), and / or measurement gaps. The location-based measurement reports can be based on eventD1 and can utilize execution conditions similar to condEventD1. The multiple SMTCs can be configured per carrier for a given set of cells, for example, based on propagation delay differences, feeder link delays, and / or serving / neighbor cell satellite ephemeris. In an example, the measurement gaps can be configured using the same or similar propagation delay differences calculated for the SMTCs.

[0085] A stationary WTRU may be expected to perform mobility functions for LEO deployments. Based on this, extended mobility is of particular interest in LEO deployments. Due to the movement of the satellite, a stationary WTRU may be expected to perform mobility, for example, every about 7 seconds, depending on the deployment characteristics.

[0086] The extension to IDLE / INACTIVE cell reselection may include new measurement rules. Two main extensions can be based on the WTRU distance from the cell reference point and the time (e.g., indicated by t-Service) at which the virtual terrestrial cell can stop providing service to the current area. The cell reference point, or the parameters used to evaluate the distance condition (e.g., t-Service and distanceThresh), can optionally be broadcast in the SIB (e.g., SIB19). SIB19 can be a new system information block that carries NTN-specific information.

[0087] A location-based extension can enable measurement relaxation, for example, when the WTRU is located within a threshold (e.g., distanceThresh) from the cell reference point. In one or more implementations, the cell reference point can be the cell center. In some examples, there can be a cell reference point that is not the cell center. Based on the condition being satisfied, the WTRU may not perform in-band measurements, measurements of cells between equal or lower priority NR frequencies, and / or measurements of inter-RAT frequency cells. For example, the WTRU may not need to perform the above if all of the following conditions are satisfied. The serving cell satisfies Srxlev > SIntraSearchP and Squal > SIntraSearchQ, the WTRU has valid WTRU location information (i.e., the WTRU implementation has WTRU location information available and the distance between the WTRU and the serving cell reference position is shorter than distanceThresh).

[0088] A time-based extension can instruct the WTRU to perform cell reselection measurements in a pseudo-earth-fixed cell at a certain time based on the WTRU implementation (e.g., before t-Service). In the example, the WTRU can perform in-band measurements, inter-frequency measurements, and / or inter-RAT measurements before t-Service regardless of the distance between the WTRU and the serving cell measurement, or whether the serving cell satisfies Srxlev > SIntraSearchP and Squal > SIntraSearchQ, or Srxlev > SnonIntraSearchP and Squal > SnonIntraSearchQ. The distance and time-based measurement rules may not affect the measurements of higher priority inter-NR frequency and / or inter-RAT frequency. In the example, the WTRU can perform these measurements regardless of the remaining service time and / or the distance from the cell reference point.

[0089] In one or more cases, the WTRU may be configured for IoT NTN. In an example, the NR NTN extension may be utilized for IoT NTN. For example, the extension may include time / frequency pre-compensation, timing advance reporting, timers and monitoring window offsets, and / or cell (re)selection extensions based on t-service. Some implementations may support extensions such as disabled HARQ feedback and / or mobility extensions.

[0090] IoT NTN may utilize extensions related to the consideration of discontinuous coverage scenarios. Discontinuous coverage for NTN may refer to temporary and / or predictable coverage gaps caused by discontinuous coverage in non-geostationary satellite orbit (NGSO) deployments. This may not be a problem if continuous coverage is globally available, but continuous coverage may not be globally available in some NTN implementations (e.g., initial deployments, deployments in remote areas). IoT NTN may provide extensions to address discontinuous coverage scenarios. In some examples, these extensions may not exist for NR NTN.

[0091] Due to deterministic satellite movement, coverage gaps can be predicted and considered. IoT NTN may support additional assistance information (e.g., satellite ephemeris, as well as coverage parameters such as footprint radius, cell reference point or elevation angle, and / or service start time for neighboring cells given by t servicestart) to predict the duration of the coverage gap. While in a discontinuous coverage gap, the WTRU may be able to interrupt AS functions.

[0092] In some implementations, there may be extensions for NR NTN. For example, NR NTN extensions may include coverage extensions, NR-NTN above 10 GHz, network (NW) verified WTRU location, and / or NTN-NTN and NTN-TN mobility and / or service continuity. Coverage extensions may include extensions to PUCCH for Msg4 HARQ-ACK, DMRS bundling for PUSCH (e.g., considering NTN-specific issues), and support for receiving blind MSG3 retransmission permission. For NR-NTN above 10 GHz, for example, there may be analysis of regulations and adjacent channel coexistence scenarios, Rx / Tx requirements for satellite access nodes and WTRU classes, and / or values for physical layer parameters. Extensions for network verified WTRU location, for example, may include multi-RTT to support network verified WTRU location. Regarding NTN-NTN and NTN-TN mobility and service continuity, for example, there may be extensions related to cell (re)selection for NTN-TN and terrestrial mobile cells, handover to reduce signaling overhead, and / or Xn / NG signaling to support feeder link switching.

[0093] In some implementations, there may be extensions for IoT NTN. For example, IoT NTN extensions may include performance extensions, mobility extensions, and / or discontinuous coverage scenarios. For performance extensions, there may be support for new position fixes for WTRU pre-compensation during long connection times, invalidated HARQ feedback, and / or improved GNSS operation. For mobility extensions, there may be measurement triggers before RLF, signaling in system information of neighboring cell ephemeris, adoption of Rel-17 solutions introduced in NR-NTN for mobility extensions, and / or WTRU RRM core requirements for the listed features. For discontinuous coverage scenarios, the extensions may include specifying mobility management extensions and / or power saving extensions for discontinuous coverage.

[0094] In one or more cases, the WTRU may be configured for synchronization during the same PCI satellite handover. In some NTNs, cells transmitted from different satellites may be associated with different PCIs. A stationary WTRU may experience continuous L3 mobility when the serving satellite moves overhead and out of coverage (e.g., due to the curvature of the Earth), and a new satellite may take over coverage of the geographical area.

[0095] Figure 3 shows an example of an identical PCI handover 300 in which satellites 302a, 302b provide service to the same PCI 304a. In the case of a quasi-geostationary cell, a hard handover may occur at the same SSB frequency and the same gNB. In such a quasi-geostationary cell, a satellite handover without a PCI handover may be supported. In example 300, a PCI handover is shown. The WTRU 310 can support resynchronization to the incoming satellite 302b that provides service to the same PCI 304a. The method and implementation for WTRU resynchronization can reduce the interruption time during satellite handover and avoid unnecessary radio link failures (RLFs).

[0096] In the exemplary same PCI handover 300, the geographical area is associated with PCI 304a, 304b, 304c and gNB 306. At time T0, PCI 304a is served by the first satellite 302a. When the first satellite 302a moves out of range (e.g., due to the curvature of the earth), a second (incoming) satellite 302b connected to the same gNB 306 can start providing service to PCI 304a. This can occur at some transition point 308 that can be known in advance by the network. This solution avoids the need for L3 mobility and thus reduces signaling overhead. However, since the previous satellite 302a and the incoming satellite 302b are physically far apart, the radio state, timing advance, Doppler compensation, and UL beam direction can be very different, so the WTRU 310 has to resynchronize to the new satellite 302b. Since the PCI 304a, gNB 306, and SSB frequencies remain the same, the satellite handover can be almost transparent to the WTRU 310, and the WTRU 310 may need some assistance information to facilitate resynchronization to the incoming satellite 302b. The WTRU 310 can support resynchronization to the incoming satellite 302b that provides service to the same PCI 304a. WTRU resynchronization can shorten the interruption time during satellite handover and avoid unnecessary RLF.

[0097] The WTRU can be configured for time synchronization during the same PCI satellite handover. In one or more cases, prior to the same PCI satellite handover, the WTRU can receive a configuration for pre-reporting the timing advance and assistance information (e.g., time and incoming satellite position in the same PCI satellite handover) for the incoming satellite. The WTRU can receive a configuration to reduce the TA resynchronization time and convergence due to large-scale TA reporting. The WTRU can use the assistance information to calculate the timing advance of the incoming satellite at the time of the same PCI satellite handover and report a future TA at an offset configured relative to the satellite handover time. The future TA at an offset configured relative to the satellite handover time can indicate, for example, the TA value applied to the incoming satellite. At the time of satellite handover, the WTRU can apply the pre-calculated TA for subsequent transmissions. If the WTRU has properly reported the TA to the incoming satellite prior to the satellite handover, the WTRU can ignore the TAR triggering (e.g., due to the offsetThresholdTA configuration).

[0098] In some examples, the WTRU can calculate the TA value via ephemeris prior to the RACH. Thus, a large time difference at the time of the same PCI satellite handover (which does not require the RACH) can cause a TA synchronization failure. Relying on some triggers for TA reporting (e.g., offsetThresholdTA) can cause a large signaling overhead after the handover time. Thus, to address these system issues, the WTRU can pre-calculate the TA based on the future position of the incoming satellite at the time of the same PCI satellite handover. The WTRU can, for example, pre-report a future TA value with the indicated offset prior to the satellite handover.

[0099] The WTRU can receive (e.g., via broadcast) the time and position of the incoming satellite for the same PCI satellite handover. In one or more cases, the WTRU can receive a configuration (pre-TAR) for pre-reporting the TA to the new satellite. The WTRU can receive a configuration including one or more of an activation / deactivation indication for pre-TAR reporting, an offset prior to the satellite handover time for reporting the pre-TAR, a time period for reporting the pre-TAR, and / or a condition for reporting the pre-TAR. The condition for reporting the pre-TAR can include, for example, a delta threshold from the TA to the previous satellite. In one or more cases, the WTRU can pre-calculate the TA value of the incoming satellite using the position of the incoming satellite at the time of PCI handover. In one or more cases, the WTRU can transmit the pre-calculated TA value according to the pre-reporting configuration. In an example, the pre-reporting configuration can indicate that the TA value is associated with the incoming satellite. In one or more cases, the WTRU can apply the pre-calculated TA to the incoming satellite at the time of the same PCI satellite handover. If the WTRU was able to successfully report a future timing advance prior to the satellite handover (e.g., the WTRU receives an ACK for the transmission carrying the pre-TAR), the WTRU can ignore the trigger condition if the offsetThresholdTA is configured and the TAR is triggered due to the satellite handover. If the WTRU was unable to successfully report a future timing advance prior to the satellite handover, the WTRU can transmit the TAR at the time of the satellite handover using the pre-calculated timing advance. In one or more cases, the WTRU can transmit the UL TB using the pre-calculated TA (e.g., after the same PCI satellite handover).

[0100] The WTRU may be configured for radio link monitoring (RLM) during same PCI satellite handover. After same PCI satellite handover, the measurements and / or cell quality information associated with the previous satellite may no longer be valid. To avoid averaging of the channel state to the incoming satellite, the WTRU may reset the L3 measurement window at the time of satellite handover. The WTRU may apply a new measurement configuration (e.g., a temporary configuration with a denser set of measurement objects) and / or L3 filter coefficients after satellite handover to acquire measurements and resynchronize to the incoming satellite. The WTRU may temporarily interrupt L3 event-based reporting by some offset before and / or after satellite handover to avoid unnecessary reporting and mobility. For example, to avoid using resource reports to cells that are no longer available, the WTRU may temporarily interrupt L3 event-based reporting by some offset before satellite handover as if the channel state is about to change. Alternatively or additionally, the WTRU may temporarily interrupt L3 event-based reporting by some offset to allow time to properly measure the new channel state.

[0101] In some implementations, the WTRU may average cell measurements over time to obtain L3 cell quality. This process may delay detection of radio problems of the new satellite after satellite handover, and communicating new measurements to the incoming satellite quickly may require measurement reconfiguration after satellite handover. Measurement reconfiguration may be time-consuming considering the risk of WTRU-gNB RTT and / or RLF. In the example, to address the above problems, the WTRU may reset the L3 measurement window at the time of satellite handover and apply a pre-configured measurement configuration (e.g., with denser measurement objects) and / or filter coefficients to quickly evaluate the new channel state.

[0102] In one or more cases, the WTRU receives (e.g., via broadcast) the time at which an identical PCI satellite handover will occur. The WTRU can receive a measurement configuration to apply during the identical PCI satellite handover. The measurement configuration can include one or more of a temporary measurement configuration, expiration conditions for the temporary measurement configuration (e.g., number of measured RSs, duration, etc.), a second measurement configuration (e.g., to apply after the temporary measurement configuration), L3 filter coefficients to apply during satellite handover, and / or a configuration for interrupting measurement reports. Configuration information indicating interruption of measurement reports can include, for example, one or both of a start time and a duration.

[0103] Based on the received configuration, the WTRU can perform an identical PCI satellite handover. The WTRU can perform one or more of the following operations associated with performing an identical PCI satellite handover. Interrupt measurement reports (e.g., according to some configured prohibited duration), reset the L3 measurement window (e.g., discard previous serving cell measurements), apply a temporary measurement configuration, and / or apply updated L3 filter coefficients. In an example, the expiration conditions of the temporary measurement configuration may not be met or may not be configured, and the WTRU can perform measurements according to the temporary measurement configuration and perform filtering based on the updated L3 filter coefficients. If the expiration conditions of the temporary measurement configuration are met and no second measurement configuration is provided to the WTRU, the WTRU can return to the previous measurement configuration (e.g., the configuration used prior to the satellite handover). The WTRU can transmit measurement reports based on the new measurement configuration.

[0104] A WTRU may be configured for transmission processing for same PCI satellite handover. The WTRU resynchronization time associated with the same PCI satellite handover may vary based on the capabilities of the WTRU that determine or pre-determine synchronization aspects (e.g., timing advance, power control, etc.). During resynchronization, transmission and / or reception may be interrupted. If the network is not aware of the WTRU's resynchronization time, there may be associated risks. For example, there may be additional latency and wasted transmission opportunities (e.g., if the resynchronization time is overestimated), or a risk of missing transmission (TX) and / or reception (RX) opportunities (e.g., if the resynchronization time is underestimated). To support a resynchronization gap configuration, the WTRU may be able to transmit capabilities and / or assistance information (e.g., estimated resynchronization time) prior to the satellite handover. During resynchronization, the WTRU may be able to interrupt TX and / or RX including pre-scheduled transmissions such as configured grants, periodic CSI / SRS, etc. In one or more examples, following resynchronization, the WTRU may be able to signal (e.g., via the transmission of one or more UL signals) that synchronization has been completed. Examples of UL signals may include, but are not limited to, SR, transmission on the CG, PRACH, HARQ ACK, etc.

[0105] In some implementations, the WTRU may rely on network scheduling for pre - configured transmissions and / or periodic configurations to ensure that WTRU transmissions and / or receptions do not occur during resynchronization to a new satellite. If the network's estimation of the resynchronization time is inaccurate, resynchronization to a new satellite may result in wasted resources (e.g., over - estimation) or loss of TX and / or RX (e.g., under - estimation). To address the problems in these systems, the WTRU can provide capabilities and / or assistance information regarding the resynchronization time to assist in measurement gap configuration. The WTRU can ignore pre - configured scheduling (e.g., CG, periodic SRS, etc.) during the resynchronization time. Alternatively or additionally, the WTRU can optionally transmit an ACK to confirm that synchronization has been regained. For example, the WTRU can optionally transmit an ACK via one or more of SR, pre - provisioned resources, the earliest available CG resources, etc.

[0106] The WTRU can receive configuration information (e.g., via broadcast) indicating the time at which same - PCI satellite handover occurs. In one or more examples, the WTRU can transmit assistance information prior to same - PCI satellite handover. The assistance information can include, for example, one or more of the resynchronization duration, the capabilities of the WTRU to perform synchronization procedures (e.g., timing advance pre - calculation and reporting) prior to same - PCI satellite handover, and / or the time at which the WTRU can resume TX and / or RX after same - PCI satellite handover. The WTRU can receive configuration information for satellite resynchronization. The configuration for satellite resynchronization can include, for example, one or more of the resynchronization gap configuration, the conditions for declaring resynchronization failure, and / or the resources (e.g., UL grant, dedicated RACH preamble) for indicating that resynchronization has been successful.

[0107] The WTRU can perform same-PCI satellite handover based on configuration information indicating, for example, the time of same-PCI satellite handover. When performing same-PCI satellite handover, the WTRU can start a resynchronization gap, interrupt UL TX and / or DL RX, and perform one or more resynchronization procedures (e.g., timing advance calculation, Doppler compensation, power control, measurements) for the incoming satellite. The WTRU can start the resynchronization gap using the received configuration information. If the WTRU is configured to send an indication of resynchronization success following successful resynchronization to the satellite, it can send this (e.g., via the provided resources).

[0108] The WTRU can be configured for power control for same-PCI satellite handover. The UL TX power required by the WTRU after satellite handover can vary significantly, for example, due to a large difference in position between the previous satellite and the incoming satellite. If the power used by the WTRU is too low, the WTRU is at risk of failed reception. If the WTRU uses too much power, the WTRU bears the risk of interference and unnecessary power consumption. In an example, line-of-sight (LOS) may be likely (e.g., very likely) in the NTN environment. If LOS exists, the largest component of path loss can be due to free space propagation loss.

[0109] The WTRU can estimate free space propagation loss based on known information. For example, the WTRU can estimate free space propagation loss based on the known positions of the previous satellite and the incoming satellite (e.g., via assistance information). Using the estimated value of free space propagation, the WTRU can scale the UL transmit power for the initial transmission to the incoming satellite based on the delta distance from the previous satellite. The UL transmit power can be further controlled by the NW configuration (e.g., activation / deactivation, maximum allowable delta scaling). Further or alternatively, the UL transmit power can be conditional. For example, the UL transmit power can be based on the probability of line-of-sight (LOSPI) to the previous satellite and / or the incoming satellite exceeding a configured threshold.

[0110] In some examples, the WTRU may wait to adjust the UL transmit power until a power control command is received after satellite handover. In such examples, waiting for a power control command to adjust the UL TX power may pose a risk of transmission failure (e.g., if the initial power is too low) or interference and / or excessive power consumption (e.g., if the power control is too high). To address this, the WTRU may scale the power used for an initial UL transmission to the new satellite based on the difference in distance between the WTRU, the old satellite, and the new satellite. In an example, the scaled power may be enabled based on a configuration and / or indication in the SIB. Additionally or alternatively, the scaled power may depend on a high probability of line-of-sight (i.e., LOSPI% > X).

[0111] The WTRU can receive assistance information regarding the previous satellite and the incoming satellite (e.g., via broadcast). The assistance information can include one or more of the ephemeris data of the current serving satellite, the time of same-PCI satellite handover, and / or the position of the incoming satellite at the time of same-PCI satellite handover. In one or more cases, the WTRU can receive configuration information for calculating the UL TX power to the incoming satellite. The configuration for calculating the UL TX power can include one or more of an enable / disable indication, the maximum delta value by which the original TX power can be autonomously adjusted by the WTRU, the minimum line-of-sight probability thresholds of the previous satellite and the incoming satellite, and / or a determination regarding whether the WTRU indicates how much the UL TX power and / or UL TX power level has been adjusted (e.g., within a first transmission). In one or more cases, the WTRU can obtain updated WTRU information (e.g., via GNSS). The WTRU can calculate the WTRU-satellite distance for each satellite at the time of same-PCI satellite handover (e.g., using satellite assistance information). In one or more cases, the WTRU can calculate the line-of-sight probability to each satellite. In an example, in the case of same-PCI satellite handover, if WTRU autonomous UL TX power adjustment is enabled and the line-of-sight conditions to the previous satellite and the incoming satellite are met, the WTRU can adjust the UL TX power (e.g., proportional to the relative distance between the two satellites). The WTRU can transmit an initial UL transmission using the adjusted UL TX power. The WTRU can include the delta adjustment and / or the current UL TX power in the initial transmission (e.g., if configured by the network). In an example, in the case of same-PCI satellite handover, if WTRU autonomous UL TX power adjustment is not enabled and / or the line-of-sight conditions to the previous satellite and the incoming satellite are not met, the WTRU can transmit an initial UL transmission with the UL TX power used for transmission to the previous satellite.

[0112] A WTRU may be configured for beam management during same-PCI satellite handover. The serving satellite and the incoming satellite during same-PCI satellite handover may be in different positions. Thus, the WTRU can reorient the UL TX beam after the satellite handover. The WTRU can predict how to reorient the WTRU spatial filter, for example, using a reference signal (e.g., SSB / CSI-RS) from an adjacent cell transmitted by the incoming satellite that inherits the PCI. To support this mapping, the WTRU can receive an indication and / or configuration that a reference signal in a first time period (e.g., transmitted by the incoming satellite, e.g., before the satellite handover) is quasi-co-located (QCL) with a second reference signal in a second time period (e.g., after the satellite handover). Thus, the WTRU can apply the measurements taken before the handover to pre-determine the beam direction and channel state to the incoming satellite after the handover, thereby accelerating resynchronization to the incoming satellite.

[0113] In some examples, the WTRU can wait until after the satellite handover event to determine how to reorient the spatial filter and how to perform channel measurements, thus increasing the resynchronization time. To address issues in legacy systems, the WTRU can measure a reference signal from the incoming satellite (e.g., any SSB / CSI-RS from an adjacent cell) to understand how to reorient the spatial filter when the incoming satellite takes over coverage. The WTRU can receive that an indication and / or configuration of the reference signal in a first time period (i.e., before the handover) is QCL with a second reference signal in a second time period (i.e., after the handover) to link the measurements before and after the handover.

[0114] The WTRU can receive configuration information indicating the time of same PCI satellite handover (e.g., via broadcast). In one or more cases, the WTRU can receive an indication and / or configuration that a reference signal in a first time period (e.g., before satellite handover) is QCL with a second reference signal in a second time period (e.g., after satellite handover). In an example, the WTRU can measure a reference signal transmitted from an incoming satellite during the first time period. In one or more cases, the WTRU can use the reference signal from the first period to calculate a beam direction and DL path loss to the incoming satellite. At the time of same PCI satellite handover, the WTRU can reorient the UL TX beam of the WTRU (e.g., via application of an updated spatial filter) and adjust the transmit power for an initial UL transmission (e.g., based on the measured DL path loss from the first period) based on the mapping configuration and the reference signal measurements from the first time period. In an example, the WTRU can link the measurements from the first time period to the measurements in the second time period. In an example, the WTRU can use the determined UL TX beam and the transmit power calculated based on the reference signal received signal power (RSRP) of the reference signal during the first time period to transmit a same PCI satellite handover confirmation (e.g., using a MAC CE or a preconfigured PUCCH).

[0115] Note that the term "previous satellite" can refer to the satellite that provides service to the PCI before the same PCI satellite handover. Further, note that the term "incoming satellite" can refer to the satellite that provides service to the PCI after the same PCI satellite handover. Note that the term "temporary measurement configuration" can refer to the measurement configuration applied when, or near when, the same PCI satellite switches, for example, to support rapid resynchronization to the incoming satellite. Further, note that the term "resynchronization gap" can refer to the period indicated or configured by the network during which the WTRU is expected to perform one or more aspects of resynchronization to the incoming satellite during the same PCI satellite handover. Also, note that the term "WTRU autonomous power adjustment" can refer to the adjustment of the UL transmission power by the WTRU for the initial UL transmission to the incoming satellite after the same PCI satellite handover.

[0116] The methods and embodiments described herein may refer to examples of same PCI satellite handovers. However, it should be understood that the embodiments may be applicable to other non-terrestrial mobility scenarios, including but not limited to feeder link handovers, quasi-geostationary cell changes, and / or inter-satellite mobility and / or cell (re)selection (e.g., by replacing "same PCI satellite handover" in a given solution with one or more of the above scenarios). Further, it should be understood that the embodiments may be applicable to multi-TRP scenarios where multiple TRPs provide services to a PCI, and to resynchronization during RACH-less handovers. Further, the embodiments described herein can support resynchronization extensions (e.g., faster resynchronization) for incoming satellites during same PCI satellite handovers. Thus, the methods and embodiments can reduce the service interruption time and / or the risk of RLF due to synchronization misalignment. In examples, these embodiments enable pre-synchronization, thereby reducing the risk of congestion caused by signaling overhead after satellite handover. It should be noted that the embodiments discussed herein may be combined with one or more of the other embodiments discussed herein.

[0117] The WTRU may be configured with configuration and / or assistance information to support resynchronization to an incoming satellite. To support same PCI satellite handover resynchronization, the WTRU may receive assistance information and / or configuration from the network. The assistance information and / or configuration may be provided via, for example, dedicated signaling (e.g., via RRC signaling, MAC CE, or DCI), broadcast in system information, or both. For example, the WTRU may receive assistance information, such as information related to same PCI handover time and adjacent satellite positions, in broadcast fashion, and the WTRU may receive configuration information for TA calculation, measurement reporting, resynchronization gap configuration, power control, and / or beam management in dedicated fashion (e.g., via RRC). In one or more cases, the WTRU may receive and maintain system information updated at a time prior to a same PCI satellite handover (e.g., via configuration). The WTRU may receive and maintain system information updated at a time prior to a same PCI satellite handover to minimize the risk of resynchronization failure and ensure that the necessary information is available at the time of a same PCI satellite handover.

[0118] WTRU configurations and / or assistance information provided in a dedicated manner may, in some cases, override assistance information received via broadcast indications. For example, the WTRU may receive one or more of the following assistance information and / or configurations to support same PCI satellite handover resynchronization. Time of same PCI satellite handover (e.g., 10:31:20 UTC), location of incoming satellite at same PCI satellite handover, location of previous satellite at same PCI satellite handover, ephemeris data of incoming satellite (e.g., to support WTRU prediction of incoming satellite location at same PCI satellite handover), ephemeris data of previous satellite (e.g., to support WTRU prediction of previous satellite location at same PCI satellite handover), common time information of incoming satellite and / or previous satellite (e.g., feeder link delay, kmac, etc.) at same PCI satellite handover, information and / or configuration to support pre-calculation and reporting of timing advance to incoming satellite, information and / or configuration to support radio link monitoring, information and / or configuration for resynchronization gap and RX / TX interruption, information and / or configuration to support WTRU autonomous UL power adjustment, information and / or configuration to support beam management, information and / or configuration to support resynchronization status indication.

[0119] In one or more examples, the WTRU may be configured to request incoming satellite assistance information during an identical PCI satellite handover. The WTRU may be able to request assistance information to support resynchronization to the incoming satellite during an identical PCI satellite handover. For example, if the WTRU was unable to obtain one or more information fields necessary to complete resynchronization prior to the identical PCI satellite handover, the WTRU may be able to trigger a request. Alternatively or additionally, the WTRU may be able to trigger a request for assistance information based on connection establishment (e.g., at initial access, at service resume) or mobility. In one or more cases, the request for assistance information may be sent via, for example, UCI, SR, RACH messaging (e.g., MSGA, MSG3, MSG5), PUSCH, MAC CE, and / or RRC signaling. The assistance information request may include a general request (e.g., a flag indicating that all available information is requested). The assistance information may indicate one or more specific information fields to be provided to the WTRU.

[0120] The WTRU may be configured for time synchronization for an identical PCI satellite handover. Since the incoming satellite and the previous satellite during an identical PCI satellite handover are physically located very far apart, the WTRU may experience a large difference in timing advance when the satellite handover occurs. In an example (e.g., a legacy implementation), the WTRU may be able to calculate a TA value via ephemeris prior to RACH. Based on this, there may be a TA difference during an identical PCI satellite handover (which may not require RACH), which may cause a TA synchronization failure. In the example, relying on existing triggers for TA reporting (e.g., offsetThresholdTA) may cause congestion after a satellite handover, for example, due to signaling overhead from large-scale TA reporting triggering.

[0121] The methods and embodiments described herein may reduce TA resynchronization time and / or reduce the risk of convergence after satellite handover (e.g., due to large-scale TA reporting). For example, the WTRU may pre-compute the TA value based on the future position of the incoming satellite at the time of same-PCI satellite handover and pre-report the future TA value at the indicated offset prior to the satellite handover.

[0122] In one or more implementations, the WTRU may be configured to pre-compute the timing advance to the incoming satellite. The WTRU may pre-compute the TA to the incoming satellite for the same-PCI satellite handover time. The WTRU may pre-compute the TA to enable, for example, fast timing synchronization to the incoming satellite after same-PCI satellite handover. In an example, the network may control (e.g., enable / disable) the WTRU's ability to pre-compute the TA via one or more of a configured explicit RRC, an indication in broadcast signaling, and an (in)activation command (e.g., via MAC CE). The network may configure a window (e.g., a time period) and / or an offset from the same-PCI satellite handover for the WTRU to pre-compute the TA. If the WTRU is unable to determine the future TA by expiration of this time period or by the indicated time, the WTRU may not pre-compute the timing advance. If timing advance pre-computation is enabled and the WTRU is unable to perform the pre-computation, the WTRU may send a report or indication to the network.

[0123] To support TA pre - calculation, the WTRU can use the configuration and / or assistance information corresponding to the incoming satellite to determine, for example, common timing information (e.g., feeder link delay) and / or the position of the satellite at the time of same - PCI satellite handover. This information may be, for example, the explicit position of the satellite at the time of same - PCI satellite handover. Alternatively or additionally, the WTRU can use the ephemeris data of the incoming satellite to predict the position of the satellite at the time of same - PCI satellite handover. The WTRU can obtain the position of the WTRU (e.g., via GNSS) and calculate the distance between the WTRU and the incoming satellite at the time of same - PCI satellite handover. Using the distance between the WTRU and the incoming satellite to estimate the service link delay, the WTRU can add the common timing information from the incoming satellite to determine the complete timing advance between the WTRU and the incoming satellite at the time of same - PCI satellite handover. The WTRU can store the pre - calculated values applicable to UL transmissions at the time of same - PCI satellite handover (or another explicitly indicated time) and / or subsequent UL transmissions.

[0124] In one or more cases of timing advance pre - calculation, the WTRU can be requested and / or triggered by the network to report the position of the WTRU for the network to calculate the WTRU timing advance. The WTRU can be requested and / or triggered, for example, at an offset before the same - PCI satellite handover to report the position of the WTRU. In some cases, the WTRU can be requested and / or triggered to report the WTRU position estimated at the time of satellite handover. In an example, the network can provide a timing advance command along with the associated activation time. The associated activation time may be, for example, the same - PCI satellite handover. In one or more cases, the WTRU can apply the TA value to transmissions occurring after the activation time.

[0125] When the WTRU pre-reports a TA value, the WTRU can receive additional TA adjustments from the network before satellite handover. For example, the network may (e.g., explicitly) indicate whether the TA command is for the current TA (e.g., to the previous satellite) or for a future TA (e.g., to the incoming satellite).

[0126] In one or more cases, the WTRU may be provided with two types of ephemeris information for determining a timing advance value. The first type of ephemeris information can be used to determine one or more transmission parameters for current uplink transmissions. The first type of ephemeris information can be used to determine one or more transmission parameters for a first time window. The transmission parameters can be, for example, WTRU-specific and / or cell-specific timing advance values, K_offset, K_mac, etc. The second type of ephemeris information can be used to determine one or more transmission parameters for future uplink transmissions. The second type of ephemeris information can be used to determine one or more transmission parameters for a second time window. In one or more cases, the first type of ephemeris information may be associated with the current satellite, and the second type of ephemeris information may be associated with the incoming satellite. In one or more cases, the second type of ephemeris information may be provided by the current satellite. In one or more cases, one or more ephemeris information may be configured or provided to the WTRU (e.g., via higher layer signaling), and each ephemeris information may be indicated by time information or associated with time information. The time information can include, for example, a validity timer, a timestamp, a validity duration, a start time, a start / end time, etc.

[0127] The WTRU can report the timing advance to the incoming satellite. The WTRU can report the TA based on configuration. The WTRU can report a pre-computed TA to the incoming satellite prior to the same PCI satellite handover. The WTRU can report the pre-computed TA to the incoming satellite to reduce the congestion after the same PCI satellite handover caused by the large-scale TAR. The WTRU TA pre-report (i.e., pre-TAR) can comply with a configuration that can include one or more of the following: an activation / deactivation indication, an offset from the same PCI handover time to execute the pre-TAR, a window (e.g., a time period) for reporting the pre-TAR, and / or a resource (e.g., UL scheduling grant) for reporting the pre-TAR (e.g., service link TA vs. full TA) as to which information fields should be included within the pre-TAR.

[0128] The WTRU can pre-report the TA to the incoming satellite. For example, the WTRU can pre-report the timing advance to the incoming satellite when a valid configuration is provided and / or upon an explicit network request. Alternatively or additionally, the WTRU can pre-report the TA value according to one or more pre-configured conditions. For example, the WTRU can transmit the pre-TAR when the difference in TA between the previous satellite and the incoming satellite is greater than a threshold.

[0129] When the timing advance pre-report is enabled and all configured conditions are met, the WTRU can trigger the transmission of a pre-TAR. The pre-TAR may include one or more of the following. An explicit indication that the TAR corresponds to a future timing advance value (e.g., an incoming satellite at the same PCI satellite handover), an absolute TA value corresponding to the complete WTRU-gNB timing advance, an absolute TA value for the service link (e.g., the WTRU-incoming satellite timing delay), a delta from the currently applied timing advance (e.g., to the previous satellite), information used to pre-calculate the TA (e.g., the position and timing information of the incoming satellite), and / or an estimated value of the WTRU as to when it is time synchronized (e.g., when the WTRU applies the TA value to subsequent UL transmissions).

[0130] In one or more cases, the WTRU may be configured to perform one or more operations at the same PCI satellite handover. At the same PCI satellite handover (or when explicitly indicated activation), the WTRU can apply the pre-calculated TA value and use that value for subsequent transmissions. If the WTRU is configured with offsetThresholdTA and the application of the new TA value triggers a timing advance report (TAR), the WTRU can ignore the TAR trigger if the WTRU has already pre-reported the TA value to the incoming satellite. The WTRU can ignore the TAR trigger by not triggering a TAR and sending an updated report. In an example, the WTRU can ignore the trigger conditional on confirmation that the pre-reported timing advance value was successfully received. The WTRU can assume successful reception, for example, based on the reception of a HARQ-ACK.

[0131] Figure 4 is a flowchart showing process 400 of pre-computing timing advance and reporting to an incoming satellite during the same PCI satellite handover. In one or more cases, prior to the satellite handover, the WTRU can receive TA report configuration and information regarding the time and position of an adjacent satellite at the satellite handover point. At 402, the WTRU can receive assistance information regarding the incoming satellite. The assistance information received at 402 can include one or more of the time of the same PCI satellite handover, the position of the incoming satellite in the same PCI satellite handover, and / or the ephemeris data of the incoming satellite. At 404, the WTRU can receive configuration information for pre-reporting the incoming satellite timing advance. For example, the configuration information received at 404 can include an enable / disable indication, a reporting time offset from the same PCI satellite handover time, a time window for pre-reporting the same PCI satellite handover, a resource for reporting, and / or a conditional threshold (e.g., a delta time) for enabling the pre-reporting.

[0132] At 406, the WTRU can pre-compute the timing advance to the incoming satellite for the same PCI satellite handover time (e.g., when enabled and all configured conditions are met). If the WTRU is configured to pre-report the timing advance at 408 and the pre-report condition is met at 410, the WTRU can send a timing advance report including the TA to the incoming satellite at 412. The WTRU can report the new TA with a configured offset to the handover time. The WTRU can report the new TA with a configured offset to the handover time and can indicate the timing advance value to the new satellite. If the WTRU is not configured to pre-report the timing advance at 408, or if the WTRU has sent the pre-report TA at 412, the WTRU can wait for the same PCI satellite handover time at 414. At the same PCI satellite handover determined at 414, the WTRU can apply the pre-computed TA to the new satellite at 416. The WTRU can apply the new timing advance at or during the satellite handover. At 418, an OffsetThresholdTA can be configured. If the OffsetThresholdTA is configured (e.g., as determined at 418), the WTRU can ignore the trigger for reporting the TA if the TA has been pre-reported. For example, at 420, the WTRU can determine that the TA has been successfully pre-reported and can ignore the trigger at 422. If it is not determined at 420 that the TA has been pre-reported, the WTRU can send a TAR at 424.

[0133] In an example, the WTRU can perform one or more of the following to support time synchronization during a same PCI satellite handover. For example, the WTRU can receive the time and location of the incoming satellite (e.g., via broadcast) during a same PCI satellite handover. The WTRU can receive a configuration for pre-reporting a timing advance to the new satellite (pre-TAR). The configuration for pre-reporting the timing advance can include one or more of an enable / disable indication for pre-TAR reporting, an offset prior to the satellite handover time for reporting the pre-TAR, a time period for reporting the pre-TAR, and a condition for reporting the pre-TAR (e.g., a delta threshold from the timing advance to the previous satellite). The WTRU can pre-calculate a timing advance value to the incoming satellite using the location of the incoming satellite at PCI handover. The WTRU can transmit the pre-calculated TA value according to the pre-report configuration. In one or more cases, the pre-report configuration can explicitly indicate that the TA value is associated with the incoming satellite. The WTRU can apply the pre-calculated timing advance to the incoming satellite during a same PCI satellite handover. If the WTRU has successfully reported a future timing advance prior to the satellite handover (e.g., the WTRU has received an ACK for a transmission carrying the pre-TAR), the WTRU ignores the trigger condition based on the offsetThresholdTA being configured and the TAR being triggered due to the satellite handover. If the WTRU does not successfully report a future timing advance prior to the satellite handover, the WTRU transmits a TAR at satellite handover using the pre-calculated timing advance. In one or more cases, the WTRU transmits a UL TB using the pre-calculated timing advance.

[0134] A WTRU may be configured for RLM for same PCI satellite handover. In an example, in the case of Radio Link Monitoring (RLM), the WTRU may average cell measurements over time to obtain L3 cell quality. After a same PCI satellite handover, the measurements and / or cell quality information associated with the previous satellite may no longer be valid. This may result in a delay in detecting radio problems for the incoming satellite after the satellite handover. The delay detection can be partially resolved by obtaining many new measurements immediately after the satellite handover. Obtaining new measurements for the incoming satellite may require measurement reconstruction after the satellite handover. This process may be time consuming, for example, considering the risk of WTRU-gNB RTT and RLF. The methods and embodiments described herein may relate to RLM extensions to address these problems, such as delay detection. For example, the WTRU may reset the L3 measurement window at satellite handover, apply a pre-configured measurement configuration (e.g., having a denser measurement object), and / or apply a filter coefficient to quickly evaluate the new channel state.

[0135] A WTRU may be configured for measurement configuration after a same PCI satellite handover. In an example, the WTRU may receive measurement configuration information for application at the time of same PCI satellite handover. The measurement configuration may include, for example, a denser configuration of measurement objects to quickly obtain the channel state to the incoming satellite. In some examples, the measurement configuration may replace all or part of the current measurement configuration. For example, the WTRU may delete and / or reconfigure one or more aspects of the current configuration. In one or more cases, the new measurement configuration may add one or more additional measurement objects and / or identification information to the current configuration. The new measurement configuration may modify (e.g., add / delete / reconfigure) other aspects of the measurement configuration, including but not limited to, reporting configuration, quantity configuration, measurement gap, etc.

[0136] The WTRU can receive and store a measurement configuration before a same PCI satellite handover. The measurement configuration may optionally include conditions and / or instructions that can be applied during a same PCI satellite handover. In an example, the WTRU may obtain the conditions and / or instructions, for example, via broadcast same PCI satellite handover assistance information. In the example, the measurement configuration may include an explicit "activation time", where the measurement configuration explicitly includes the time for applying the measurement configuration. The WTRU can apply a new measurement configuration based on satisfaction of the conditions (e.g., at the activation time / time of the same PCI handover).

[0137] The measurement configuration may include one or more expiration conditions. The expiration conditions may hereinafter be referred to as "temporary measurement configurations". The expiration conditions may be time-based. For example, the time-based expiration condition may be an explicit time. The time-based expiration condition may correspond to the end of a time period that starts when the measurement configuration is applied. The expiration conditions may be based on the number of measured reference signals (e.g., SSB / CSI-RS) and / or measurement objects. The expiration conditions may be based on a determination that stable channel quality has been established. For example, the expiration conditions may be based on, but not limited to, channel quality metrics such as measurement variance or standard deviation. The expiration conditions may be based on whether a measured value (e.g., RSRP / RSRQ / SINR value) exceeds or falls below a threshold. The expiration conditions may correspond to the activation of a second measurement configuration.

[0138] In one or more examples, the WTRU may apply a subsequent measurement configuration, e.g., a second configuration, based on satisfaction of a termination condition. The second configuration may have been received and may be stored by the WTRU prior to satisfaction of the termination condition. In an example, the second configuration may include an indication of a user selection to apply the second configuration upon termination of the first measurement configuration. In an example, the measurement configuration applied upon same PCI satellite handover may include an indication to store the previous measurement configuration. For example, the indication to store the previous measurement configuration may correspond to the configuration prior to the same PCI satellite handover. In an example, the WTRU may return to the previous measurement configuration based on satisfaction of one or more of the termination conditions.

[0139] The WTRU may be configured for L3 filtering after the same PCI handover. In an example, the WTRU may reset the L3 measurement window based on the same PCI satellite handover. The WTRU may reset the L3 measurement window to avoid detection of a poor channel state resulting from, e.g., averaging measurements to the incoming satellite using measurements from the previous satellite in the same PCI satellite handover. In an example, the WTRU may discard one or more measurements associated with the previous satellite. For example, the WTRU may consider a channel and / or cell quality derivation (e.g., RSRP / RSRP / SINR) including one or more measurements associated with the previous satellite to be invalid. The invalid measurement results may, for example, be discarded and not used for event evaluation, cell (re)selection or mobility determination and / or may not be included in the measurement report.

[0140] A WTRU can receive a new or revised set of L3 filtering coefficients. For example, the WTRU can receive a new or revised set of L3 filtering coefficients for application during the same PCI satellite handover. In some cases, the filtering coefficients can be provided and stored with the measurement configurations described herein. In some cases, the filtering coefficients can be received independently. Similar to the temporary measurement configurations, the set of L3 filter coefficients can include one or more of an activation condition, an expiration condition, an indication to store the previous set of L3 filter coefficients to be used upon expiration, and a second set of L3 filter coefficients to be applied after expiration of the temporary L3 filter coefficients.

[0141] The WTRU can be configured to perform measurement reporting before and / or after the same PCI satellite handover. To avoid reporting measurement values that will soon become invalid or to avoid triggering measurement reporting before acquisition of channel quality to a new cell, the WTRU can interrupt measurement reporting during or prior to the same PCI satellite handover. In some cases, the WTRU can determine whether to interrupt measurement reporting prior to satellite handover based on an explicit configuration from the network. In other cases, the WTRU can determine whether to interrupt measurement reporting prior to satellite handover based on an explicit configuration broadcast in the system information (e.g., within the same PCI satellite handover assistance information). Within the interruption configuration and / or indication, the WTRU can include one or more of a condition to initiate interruption of measurement reporting, a condition to resume measurement reporting, an aspect of the measurement reporting to which the interruption applies (e.g., a subset of events, report type, etc.), and an exception to measurement reporting interruption.

[0142] The WTRU determines when to start a measurement report interruption based on time. For example, the WTRU can interrupt the measurement report during the same PCI satellite handover. In some cases, the start time can occur at an offset from the same PCI satellite handover (e.g., 10 seconds before the handover) or an explicit time (e.g., 10:30:02 UTC). In one or more cases, the network can optionally provide the time period / duration that the measurement report can be interrupted and maintained by the WTRU (e.g., via a prohibit timer).

[0143] In the example, the interruption can be applied to one or more aspects of the measurement report. For example, the interruption can be applied to event-triggered measurement reports, periodic measurement reports, or both. In the example, the interruption can be applied to a subset of measurement events (e.g., the measurement report triggered by A3 is interrupted). In the example, the interruption can be applied to measurement reports triggered by measurements performed on one or more cells or measurement objects / IDs. In some cases, for example, based on multiple event-based measurement triggers being satisfied, based on a particular event-based trigger being satisfied, and / or to support recovery procedures such as radio link failure, the interruption can be disabled.

[0144] The WTRU can resume the measurement report based on one or more of the following examples. The WTRU can resume the measurement report, for example, based on the expiration of a temporary measurement configuration. The WTRU can resume the measurement report, for example, based on the reconfiguration of the measurement configuration. The WTRU can resume the measurement report, for example, based on the activation of a second measurement configuration. The WTRU can resume the measurement report, for example, based on the satisfaction of measurement-based conditions (e.g., RSRP / RSRP / SINR exceeds or falls below some threshold). The WTRU can resume the measurement report, for example, after a certain duration. The WTRU can resume the measurement report, for example, based on reaching an absolute time.

[0145] A WTRU may be configured using an association between a measurement report and ephemeris information. The WTRU may be configured using one or more ephemeris information for one or more satellites for same PCI satellite handover. The WTRU may perform L3 filtering of measurement values when the associated satellite position changes within a specific threshold. For example, when the associated satellite position change is greater than the threshold, the WTRU may reset the L3 filter and start L3 filtering of the measurement values. In the example, the satellite position change may be determined based on the ephemeris identification information associated with the measurement values. For example, the WTRU may be provided with one or more ephemerides, and each ephemeris may be associated with identification information. The identification information may indicate which ephemeris id is active and / or which ephemeris id becomes active from which start time (e.g., associated with an incoming satellite). In one or more cases, the satellite position change may be determined based on the AoD of the beam at the satellite. For example, the L3 filter reset for measurement may be triggered when the AoD of the beam change (e.g., serving beam) is greater than the threshold. In one or more cases, the length of the L3 filter may be determined based on one or more parameters of the ephemeris information. For example, when the speed of the satellite is faster than the threshold, a first L3 filter length may be used. When the speed of the satellite is slower than the threshold, a second L3 filter length may be used, and the first L3 filter length may be shorter than the second L3 filter length.

[0146] In one or more examples, the WTRU can reset the measurement window upon satellite handover to avoid the channel state to the new satellite being averaged. The WTRU can apply a new measurement configuration, such as a temporary configuration with a denser set of measurement objects. The WTRU can filter coefficients after satellite handover to quickly obtain measurements and resynchronize to the new satellite. The WTRU can temporarily interrupt L3 event-based offset reporting before satellite handover (when the channel state is about to change and there is no need to use resources to report cells that are no longer available) and / or after satellite handover (to allow time to properly measure the new channel state). The WTRU can temporarily interrupt the reporting of any L3 event-based offset before satellite handover, for example, when the channel state is about to change and there is no need to use resources to report cells that are no longer available. The WTRU can temporarily interrupt L3 event-based offset reporting after satellite handover, for example, to allow time to properly measure the new channel state to avoid unnecessary reporting.

[0147] FIG. 5 is a flowchart showing an exemplary process 500 of wireless link monitoring during the same PCI satellite handover. The WTRU can perform one or more of the following to support RLM during the same PCI satellite handover. At 502, the WTRU can receive assistance information regarding the incoming satellite. For example, the WTRU can receive (e.g., via broadcast) the time at which the same PCI satellite handover will occur. At 504, the WTRU can receive configuration information for RLM of the incoming satellite. The WTRU can receive a measurement configuration to apply during the same PCI satellite handover. The measurement configuration can include, for example, but not limited to, a temporary measurement configuration, expiration conditions for the temporary measurement configuration (e.g., the number of measured RSs, duration, etc.), a second measurement configuration (e.g., to apply after the temporary measurement configuration), L3 filter coefficients to apply during satellite handover, start time, and one or more of the configurations for interrupting the measurement report including duration.

[0148] At 506, the WTRU can determine to interrupt the measurement report based on the configuration information. For example, if configured to interrupt the report prior to the same PCI satellite handover, the WTRU can interrupt the measurement report at 508. At 510, based on the received configuration information, the WTRU can wait for the start time of the same PCI satellite handover. At 512 (e.g., the time of the same PCI satellite handover), the WTRU can perform one or more of the following operations based on the received configuration information: reset the L3 measurement window, apply the temporary measurement configuration and / or filter coefficients, interrupt the measurement report if still valid, and / or perform measurements on the incoming satellite.

[0149] At 514, the WTRU determines that the conditions for resuming measurement reporting are met and, at 518, can resume measurement reporting. At 516, the WTRU can determine whether invalidation conditions have been provided. If the expiration conditions of the temporary measurement configuration have not been provided, the WTRU can continue to perform measurements according to the temporary measurement configuration at 520. At 522, the WTRU can determine whether the expiration conditions of the temporary measurement configuration are met. If the expiration conditions of the temporary measurement configuration are not met (or not configured), the WTRU can perform measurements according to the temporary measurement configuration and filter based on the updated L3 filter coefficients. In an example, the WTRU can receive a second measurement configuration at 524. If the expiration conditions of the temporary measurement configuration are met and the WTRU receives a second measurement configuration, the WTRU can apply the second measurement configuration at 526. If the expiration conditions of the temporary measurement configuration are met and the second measurement configuration is not received, the WTRU can determine at 524 to return to the previous measurement configuration (e.g., used prior to satellite handover). For example, at 528, the WTRU can apply the previous (e.g., prior to satellite handover) measurement configuration. In one or more cases, the WTRU can transmit a measurement report based on the new measurement configuration.

[0150] A WTRU may be configured for transmission processing for same-PCI satellite handover. The WTRU resynchronization time for same-PCI satellite handover may vary based on the capabilities of the WTRU that determine or pre-determine synchronization aspects (e.g., timing advance, power control, etc.). During resynchronization, transmission and / or reception may be interrupted. If the network is not aware of the WTRU's resynchronization time, there may be associated risks. For example, there may be additional latency and wasted transmission opportunities (e.g., if the resynchronization time is overestimated), or a risk of missing TX and / or RX machinery (e.g., if the resynchronization time is underestimated). The methods and embodiments described herein may relate to supporting an appropriate resynchronization gap configuration and WTRU TX / RX processing. For example, the WTRU may be able to transmit provisioning capabilities and / or assistance information regarding the resynchronization time to assist with resynchronization gap configuration and transmission processing during the resynchronization time.

[0151] A WTRU may be configured using assistance information for resynchronization of gap configuration during same-PCI satellite handover. The WTRU may be configured using a "resynchronization gap" to facilitate resynchronization to the incoming satellite during same-PCI satellite handover. During the resynchronization gap, the WTRU may be able to perform one or more resynchronization operations and / or procedures related to the incoming satellite. The resynchronization operations and / or procedures may include, for example, timing advance calculation, Doppler compensation, power control, measurement / RLM, and / or beam management. During resynchronization, the WTRU may be able to interrupt (or not expect to perform) DL reception and / or UL transmission. The TX and / or RX interruptions may include, for example, dynamic scheduling and pre-configured transmissions (e.g., configured grants, periodic CSI / SRS reporting, etc.).

[0152] The WTRU can provide assistance information (e.g., via MAC CE and / or RRC signaling) to support an appropriate configuration of the resynchronization gap. The WTRU assistance information for resynchronization gap configuration can include, for example, the time for performing a complete resynchronization, the time for performing one or more aspects of resynchronization (e.g., timing synchronization, UL power control), the ability to perform one or more aspects of resynchronization prior to a same PCI satellite handover, the estimated time of resynchronization completion (e.g., 10:32:30:00 UTC), a determination as to whether the WTRU can continue reception / transmission during the resynchronization time, the earliest time at which the WTRU can resume transmission / reception (e.g., 10:32:40:00 UTC), measurements of neighboring cells (e.g., in the case of fallback or RLF), and / or a determination as to whether one or more pre-configured transmissions overlap with the resynchronization gap.

[0153] The WTRU can provide assistance information (e.g., one or more of the above) for resynchronization gap configuration. For example, the WTRU can provide one or more of the above assistance information based on an explicit network request. In an example, the WTRU can provide assistance information (e.g., one or more of the above) for resynchronization gap configuration upon connection to the network or resumption of connection (e.g., during WTRU capability transfer). In an example, the WTRU can provide assistance information (e.g., one or more of the above) for resynchronization gap configuration within a WTRU assistance information (UAI) message. In an example, the WTRU can provide assistance information (e.g., one or more of the above) for resynchronization gap configuration within a "WTRU information response" message (e.g., based on a request or instruction within a "WTRU information request" message transmitted by the network).

[0154] The WTRU can determine to send assistance information for resynchronization gap configuration based on configured conditions. For example, the WTRU can determine to send assistance information based on the current state of one or more information fields and / or the variation between previously reported information. This variation between the current state of one or more information fields and the previously reported information can be, for example, any amount of variation. In an example, the WTRU can determine to send assistance information based on the variation exceeding a configured threshold. In the example, the WTRU can determine to send assistance information at a configured time (e.g., absolute time, offset, time period) before the same PCI satellite handover. To assist with reliability, the WTRU can send assistance information regarding the HARQ process when HARQ feedback / resending is configured (e.g., HARQ mode A).

[0155] The WTRU can receive configuration information for resynchronization gap configuration. The WTRU can perform operations during the resynchronization gap based on the received configuration information. In an example, the WTRU can receive the resynchronization gap via MAC CE and / or broadcast signaling. In the example, the resynchronization gap can be directly configured via RRC signaling.

[0156] Configuration information (e.g., resynchronization gap configuration information) may include the start time of the resynchronization gap, the end time of the resynchronization gap, the duration of the resynchronization gap, a determination as to whether to interrupt one, multiple, or all UL transmissions / DL receptions during resynchronization (e.g., the network can indicate that one or more transmission / reception types such as periodic scheduling are interrupted while other types such as dynamic scheduling remain valid), a determination as to which resynchronization procedure should be performed prior to resynchronization (e.g., timing advance pre - calculation / reporting), a determination as to which resynchronization mode should be performed during the resynchronization gap, and / or one or more of the information and / or configuration for performing one or more resynchronization procedures. Configuration information including the start time of the resynchronization gap may indicate, for example, that the resynchronization gap starts at the time of the same PCI satellite handover or at some other opportunity. For example, configuration information including the start time and the resynchronization gap duration may indicate the expected end time of the same PCI satellite handover. For example, configuration information including the start time and the end time of the resynchronization gap may indicate the expected duration of the same PCI satellite handover.

[0157] In some cases, the WTRU may be able to select, request, or propose a resynchronization gap configuration (e.g., via the content of the WTRU assistance information). The network may be able to provide a positive response to the requested configuration. In some cases, the network may pre - configure, broadcast, or indicate a set of candidate resynchronization gap configurations. For example, the network may indicate the resynchronization gap configuration by transmitting and indicating an index corresponding to the configuration.

[0158] The WTRU can apply a resynchronization gap configuration for the same PCI satellite handover. In an example, the resynchronization gap configuration can be applied to one or more future satellite handover events. In an example, the WTRU can determine whether to memorize and / or maintain the current resynchronization gap configuration (e.g., used in a subsequent same PCI satellite handover event) based on an indication (e.g., an explicit indication) and / or configuration. In an example, the WTRU can apply the same gap configuration for subsequent same PCI satellite handovers until the configuration is deactivated and / or until a revised resynchronization gap configuration is received.

[0159] In one or more cases, to support the resynchronization gap configuration, the WTRU can transmit capabilities and / or assistance information (e.g., estimated resynchronization time) prior to the satellite handover. Prior to the same PCI satellite handover, the WTRU can receive configuration information for the resynchronization gap. The configuration information for the resynchronization gap can include, for example, an indication of the start time, end time, and / or duration of the resynchronization gap. At the same PCI satellite handover, the WTRU can start the resynchronization gap. In an example, the WTRU can start the resynchronization gap with an offset from the same PCI satellite handover (e.g., based on an indication in the configuration). While the gap is in progress, the WTRU can interrupt TX and / or RX. In some cases, the WTRU can interrupt pre-scheduled transmissions such as, for example, configured grants, periodic CSI / SRS, etc. The WTRU can signal that synchronization is complete via transmission of UL signals, e.g., but not limited to, SR, transmission on CG, PRACH, HARQ ACK, etc.

[0160] FIG. 6 is a flowchart showing an exemplary transmission process and measurement gap configuration process 600 during the same PCI satellite handover. In one or more cases, the WTRU can perform one or more of the following steps to support the transmission process and measurement gap configuration during the same PCI satellite handover. At 602, the WTRU can receive assistance information associated with the incoming satellite. For example, the WTRU can receive (e.g., via broadcast) the time at which the same PCI satellite handover will occur. Prior to the same PCI satellite handover, at 604, the WTRU can transmit assistance information. The assistance information can include one or more of a resynchronization duration, the WTRU's ability to perform synchronization procedures (e.g., timing advance pre-calculation and reporting) prior to the same PCI satellite handover, and / or a determination of when the WTRU can resume RX / TX after the same PCI satellite handover. At 606, the WTRU can receive configuration information for satellite resynchronization. The configuration information for satellite resynchronization can include one or more of configuration information for a resynchronization gap, conditions for declaring a resynchronization failure, and / or resources (e.g., UL grant, dedicated RACH preamble, etc.) for indicating that the resynchronization has been successful.

[0161] Based on the configuration and / or assistance information, at 608, the WTRU can wait for the same PCI satellite handover to occur. At 610, upon satellite handover, the WTRU can start a resynchronization gap and interrupt UL transmission and / or DL reception. At 610, the WTRU can perform one or more resynchronization procedures (e.g., timing advance calculation, Doppler compensation, power control, measurements) for the incoming satellite. At 612, the WTRU may succeed in resynchronizing to the satellite. If the resynchronization is successful, at 616, the WTRU can resume DL reception and UL transmission. At 620, if the WTRU is configured to confirm or indicate resynchronization success, the WTRU can send a resynchronization success indication (e.g., using the provided resources). At 612, the WTRU may fail to resynchronize to the satellite. At 614, the WTRU can time out and determine that the resynchronization has failed. If the timeout has not been reached, the WTRU can continue to perform the resynchronization gap procedure based on the configuration at 610. At 614, the WTRU can determine that the resynchronization has failed, and if the timeout has been reached, at 618, the WTRU can declare an RLF and perform the associated recovery operations.

[0162] In one or more cases, a WTRU may be configured for power control during same PCI satellite handover. The UL TX power required after satellite handover may vary significantly due to a large difference in position between the previous satellite and the incoming satellite. If the WTRU relies on legacy closed-loop power control (i.e., the WTRU waits until a power control command is received after satellite handover) to adjust the UL transmit power, the WTRU may risk transmission failure if the initial transmit power is too low or is interference. Further, the WTRU may risk excessive power consumption if the initial transmit power is too high. Embodiments described herein relate to support for power control during same PCI satellite handover. Further, embodiments provide a process for the WTRU to adjust the power for initial UL transmission to a new satellite based on the difference in distance between the WTRU and the old and new satellites.

[0163] A WTRU may be configured for autonomous TX power adjustment during same-PCI satellite handover. The WTRU may adjust the power to the incoming satellite after the same-PCI satellite handover. For example, the WTRU may adjust the power to the incoming satellite after the same-PCI satellite handover to avoid using too much or too little UL power for the initial transmission. The ability of the WTRU to autonomously adjust the transmission power may be enabled / disabled by the network. For example, the network may enable / disable the ability of the WTRU to autonomously adjust the transmission power via RRC configuration or indication such as, but not limited to, broadcast signaling in SIB, MAC CE, and / or DCI. The network may provide additional information / configurations for calculating the initial UL TX power to the incoming satellite. The additional information / configurations may include the maximum delta value of the original TX power that may be autonomously adjusted by the WTRU, the maximum and / or minimum absolute TX power, the mapping between distance and power adjustment (e.g., 100 km = 1 dB), the mapping between distance and scaling factor (e.g., 100 km = 1.25x), the determination of how to adjust the TX power (e.g., scaling by a factor, addition / subtraction of power), the determination of whether to scale the total transmission power or one or more components of the transmission power (e.g., path loss), assistance information corresponding to the transmission characteristics of the incoming satellite (e.g., antenna gain), and one or more of the free space factors applied to calculate the change in path loss.

[0164] In an example, the WTRU may autonomously adjust the transmission power. For example, the WTRU may autonomously adjust the transmission power based on the satisfaction of one or more conditions. For example, the WTRU may calculate the line-of-sight probability to the previous satellite and the incoming satellite. If the line-of-sight probability (e.g., LOSPI) to the previous satellite, the incoming satellite, or both satellites is below a configured threshold (e.g., 95%), the WTRU may not autonomously adjust the transmission power. In some cases, the network may provide one threshold to be used for the LOS evaluation for both the incoming and previous satellites. In some cases, the network may provide a threshold for each satellite.

[0165] The WTRU can evaluate and / or determine the incoming satellite path loss during the same PCI satellite handover. In an example, to support WTRU autonomous power adjustment, the WTRU can determine the position of the satellite at the time of the same PCI satellite handover using assistance information corresponding to the incoming satellite. The assistance information may be, for example, the explicit position of the satellite at the time of the same PCI satellite handover. In an example, the WTRU can use the ephemeris data of the incoming satellite to predict the position of the satellite at the time of the same PCI satellite handover. The WTRU can obtain the position of the WTRU (e.g., via GNSS) and calculate the distance between the WTRU and the incoming satellite at the time of the same PCI satellite handover. The WTRU can use a similar set of procedures to determine the position of the previous satellite (e.g., at the time of the same PCI satellite handover).

[0166] When the WTRU is configured with line-of-sight conditions, the WTRU can calculate the line-of-sight probability (LOSPI) for the previous satellite and / or the incoming satellite. Whether the WTRU calculates the line-of-sight probability for one or both satellites may depend on whether the conditions require LOSPI evaluation for one or both satellites. The WTRU can calculate the line-of-sight probability using, for example, assistance information (e.g., position, ephemeris data, orbital characteristics) and / or reference signals (e.g., SSB, CSI-RS, PRS) associated with each satellite. The WTRU can receive and / or evaluate the reference signal from the incoming satellite, for example, via measurements on one or more adjacent cells transmitted from the incoming satellite.

[0167] In some examples, the LOSPI can be evaluated by the network. In such cases, the WTRU can provide the WTRU location (e.g., current location, or estimated location at the time of same PCI satellite handover). The network can provide the LOSPI associated with one or both of the satellites used in the conditional evaluation (e.g., at the time of same PCI satellite handover). In one or more other cases, the LOSPI indication can be directly evaluated by the network. The LOSPI indication evaluation can be used to enable / disable WTRU autonomous power adjustment.

[0168] In some examples, the WTRU can be configured for autonomous UL TX power adjustment during same PCI satellite handover. At the time of same PCI satellite handover (or at some point between same PCI satellite handover and initial transmission to the incoming satellite), the WTRU can determine that autonomous transmission power adjustment is enabled and configured. If any required or configured conditions are met (e.g., based on line-of-sight probability), the WTRU can adjust the transmission power for the initial transmission. If the WTRU autonomous power adjustment is disabled / inactivated, or if the autonomous power adjustment is enabled and one or more conditions are not met, the WTRU can use the transmission power from the previous satellite for the initial transmission to the incoming satellite.

[0169] The WTRU autonomous power adjustment can be based on one or more of the distance between the WTRU and the incoming satellite and / or the previous satellite, the difference (delta) between the WTRU previous satellite and the WTRU incoming satellite, the determination of how the WTRU adjusts the power (e.g., whether the WTRU adds / subtracts power and / or applies a scaling factor), the mapping or relationship between the determination of how the distance and power are adjusted, the maximum absolute (or delta) value of the original power that can be modified by the WTRU, the transmission characteristics of the incoming satellite (e.g., antenna gain), and / or the total transmission power by the WTRU.

[0170] In one or more cases, the WTRU can calculate the delta distance between the WTRU, the incoming satellite, and the previous satellite. By applying the mapping of the delta distance provided by the network to delta dB, the WTRU can determine an amount (e.g., in dB) for adjusting the power. The WTRU can adjust the total transmission power based on the configuration, or can adjust one or more components of the power calculation (e.g., the path loss value). If the delta power adjustment exceeds the maximum / minimum allowable power adjustment, the WTRU can select a boundary value. If the adjusted value exceeds the total maximum allowable transmission power by the WTRU, the WTRU can select the maximum allowable transmission power. The WTRU can apply a scaled power for initial transmission to the incoming satellite after the same PCI satellite handover. In one or more cases, the WTRU can use the delta distance and apply a free space propagation loss factor to determine the change in path loss between the incoming satellite and the previous satellite. The WTRU can adjust the transmission power accordingly to compensate for the adjusted path loss.

[0171] In one or more cases, the WTRU can indicate the characteristics of the WTRU autonomous power adjustment based on an indication or configuration. For example, the WTRU can indicate (e.g., via MAC CE or RRC signaling) a determination of how much the WTRU has adjusted the UL TX power and / or the UL TX power level (e.g., within a first transmission). In some cases, the configuration / request can include a resource (e.g., a dynamic UL grant) for sending the indication. In other cases, the configuration / request can command the WTRU to include the indication in the first transmission to the incoming satellite.

[0172] In one or more cases, the WTRU may adjust the UL transmission power for the first transmission to a new satellite based on the delta distance from the previous satellite. The UL transmission power may be further controlled by the network configuration. For example, the network configuration may enable / disable the UL transmission power. In another example, the network configuration may provide a maximum allowable delta scaling for UL transmission. In one or more cases, the UL transmission power may depend, for example, without limitation, on the condition that the probability of the line of sight to the previous and current satellite LOSPI exceeds a configured threshold.

[0173] Figure 7 is a flowchart showing an exemplary power control process during same-PCI satellite handover. In one or more cases, the WTRU may perform one or more of the following steps to support power control during same-PCI satellite handover. At 702, the WTRU may receive assistance information (e.g., via broadcast) regarding the previous satellite and the incoming satellite. The assistance information may include one or more of the ephemeris data of the current serving satellite, the time of same-PCI satellite handover, and / or the position of the incoming satellite at the time of same-PCI satellite handover. At 704, the WTRU may receive configuration information for calculating the UL TX power to the incoming satellite. The configuration may include one or more of an enable / disable indication, a maximum delta value by which the original TX power may be autonomously adjusted by the WTRU, a minimum line-of-sight probability threshold for the previous and incoming satellites, and / or a determination as to whether the WTRU indicates (e.g., within the first transmission) how much the UL TX power and / or UL TX power level has been adjusted. The WTRU may obtain updated WTRU information (e.g., via GNSS).

[0174] At 706, the WTRU can calculate one or more of the WTRU-to-satellite distances to each satellite (e.g., using satellite assistance information) and / or the line-of-sight probability to each satellite during an in-PCI satellite handover. The WTRU can obtain updated WTRU information (e.g., via GNSS). At 708, the WTRU can identify the start of an in-PCI satellite handover. At 710, if WTRU autonomous UL TX power adjustment is not enabled, the WTRU can perform any UL transmission using the original UL TX power at 712. At 710, if WTRU autonomous UL TX power adjustment is enabled, the WTRU can adjust the UL TX power to the incoming satellite. At 714, if WTRU autonomous UL TX power adjustment is enabled and the line-of-sight conditions to the previous and incoming satellites are met, the WTRU can adjust the UL TX power (e.g., proportional to the relative distance between the two satellites). The WTRU can transmit an initial UL transmission at the adjusted UL TX power. If configured by the NW, the WTRU can include the delta adjustment and / or the current UL TX power in the initial transmission. During an in-PCI satellite handover, if WTRU autonomous UL TX power adjustment is not enabled and / or the line-of-sight conditions to the previous and incoming satellites are not met, the WTRU transmits an initial UL transmission at the UL TX power used for transmission to the previous satellite. The WTRU can be configured at 716 to indicate the determined power adjustment. If the WTRU is not configured to indicate the adjustment, at 718, subsequent UL transmissions can be performed using the adjusted power. If the WTRU is configured to indicate the adjustment, at 720, subsequent UL transmissions can be performed using the adjusted power and the WTRU can indicate the power adjustment (e.g., in the transmission).

[0175] A WTRU may be configured to perform beam management during an identical PCI satellite handover. The serving satellite and the incoming satellite during an identical PCI satellite handover may be in very different positions. Thus, the WTRU may need to reorient its UL TX beam after the satellite handover. In one or more cases, the spatial filter is reoriented depending on legacy methods until a satellite handover event occurs after the satellite handover. However, reorienting the spatial filter after a satellite handover event can increase the resynchronization time and thus increase service interruption. The embodiments described herein relate to supporting an appropriate measurement gap configuration and WTRU TX / RX processing.

[0176] The WTRU can measure a reference signal from the incoming satellite (e.g., any SSB / CSI-RS from an adjacent cell) to understand how to reorient the spatial filter when the new satellite takes over coverage. The WTRU can receive that the indication / configuration of the reference signal in a first time period (i.e., before the handover) is QCL with a second reference signal in a second time period (i.e., after the handover) to link the inter-cell measurements.

[0177] In one or more cases, the WTRU may be configured with an indication and / or configuration of the QCL relationship before / after an identical PCI satellite handover. The WTRU may be provided with a QCL relationship between one or more reference signals transmitted from the incoming satellite and a reference signal associated with the serving cell. The relationship between one or more reference signals transmitted from the incoming satellite and a reference signal associated with the serving cell can be time-dependent, and the WTRU assumes that the relationship between the reference signals (e.g., from an adjacent cell transmitted from the incoming satellite) is valid after an identical PCI satellite handover (e.g., if the current serving cell is served by the same satellite as the adjacent cell shown in the mapping relationship).

[0178] In an example, the WTRU can receive an indication and / or configuration that a first reference signal from a first period (e.g., a reference signal from an adjacent cell transmitted from an incoming satellite before a same-PCI satellite handover) is QCL with a second reference signal from a second period (e.g., a reference signal within the current serving cell after a same-PCI satellite handover). The WTRU can link measurements made during a first time period to support resynchronization after a same-PCI satellite handover (e.g., determination of a spatial filter, path loss estimation, etc.). The configuration of the first or second reference signal can include, for example, identification information of the SSB including at least physical cell identification information (PCI) and an SSB index, and / or identification information of a CSI-RS resource. When the second reference signal is an SSB, the WTRU can determine that the corresponding PCI is the PCI corresponding to the serving cell.

[0179] In an example, the WTRU can be configured for beam management during a same-PCI satellite handover. Before a same-PCI satellite handover, the WTRU can perform measurements on a reference signal transmitted from an incoming satellite indicated in a mapping relationship. The WTRU can use these measurements to determine a transmission mode to apply to the serving cell after a same-PCI satellite handover, such as a spatial filter, L3 measurements, and DL path loss. During a same-PCI satellite handover, the WTRU can link measurements from these reference signals to the current serving cell. The WTRU can apply a transmission mode for subsequent UL transmissions to the incoming satellite.

[0180] In an example, the WTRU may be configured to filter samples before and after PCI switching for L3 reporting. In another example, the WTRU may utilize the most recent layer 3 filtered measurement results from a first reference signal during a first period (e.g., before the same PCI satellite switching time) to combine the most recent layer 3 filtered measurement results with first measurement results from a second reference signal during a second period (e.g., after the same PCI satellite switching time) to obtain updated filtered measurement results applicable to the second reference signal. The WTRU may utilize the updated filtered measurement results for further layer 3 filtering, measurement reporting, and determination of RSRP for path loss estimation and uplink power using subsequent measurement results.

[0181] The WTRU may be configured to determine a spatial RX beam based on the serving satellite position. In one or more cases, for a given TCI state (e.g., a beam reference signal for indicating an Rx beam at the WTRU), the WTRU may be able to use, determine, or select an RX beam based on the satellite position. For example, the WTRU may be able to use a first RX beam when the serving satellite is at a first position, a second RX beam when the serving satellite is at a second position, and so on. The WTRU may be able to estimate the satellite position based on ephemeris information (e.g., a first type of ephemeris information and / or a second type of ephemeris information). In one or more cases, the WTRU may be able to reset the L3 filter for measurements when the RX beam is changed. In one or more cases, the WTRU may be able to report RX beam information to the gNB when the Rx beam is changed.

[0182] The WTRU can reorient the spatial filter by using reference signals (e.g., SSB / CSI-RS) from neighboring cells transmitted by the satellite that will ultimately inherit the PCI. To support this mapping, the WTRU can receive an indication / configuration that the reference signal in a first time period (i.e., before satellite handover) is QCL with a second reference signal in a second time period (i.e., after satellite handover). Thus, anything measured from one satellite can be linked to the second incoming satellite.

[0183] Figure 8 is a flowchart showing a process 800 of an example of beam management during same-PCI satellite handover. In one or more cases, the WTRU can perform one or more of the following steps to support beam management during same-PCI satellite handover. At 802, the WTRU can receive assistance information for the incoming satellite (e.g., via broadcast). The assistance information can include, for example, the time indication of the same-PCI satellite handover, the position of the incoming satellite, and / or the ephemeris data of the incoming satellite. At 804, the WTRU can receive an indication / configuration that the reference signal in a first time period (e.g., before satellite handover) is quasi-collocated (QCL) with a second reference signal in a second time period (e.g., after satellite handover).

[0184] At 806, the WTRU can measure the reference signal transmitted from the incoming satellite during the first period. At 808, the WTRU can calculate the beam direction to the incoming satellite and / or the DL path loss using the reference signal from the first period based on the information obtained at 806.

[0185] At 810, upon the same PCI satellite handover, the WTRU can perform operations associated with the satellite handover. At 812, based on the mapping configuration and reference signal measurement values from the first period, the WTRU can reorient the UL TX beam of the WTRU (e.g., via the application of an updated spatial filter) and adjust the transmission power for the initial UL transmission (e.g., based on the measured DL path loss from the first period). The WTRU can link the measurement values from the first time period to the measurement values in the second time period. At 814, the WTRU can perform a UL transmission using the newly applied spatial filter and the adjusted UL power. The WTRU can use the determined UL Tx beam and the transmission power calculated based on the RSRP of the reference signal during the first time period to send a same PCI satellite handover confirmation (e.g., using a MAC CE or a pre - configured PUCCH).

[0186] In one or more cases, the WTRU can be configured with an acknowledgement of resynchronization completion after the same PCI handover. The WTRU can be configured / requested / instructed to provide an indication or acknowledgement to the serving satellite that the WTRU has restored synchronization after the same PCI satellite handover. The resynchronization indication may be an explicit indication confirming that the WTRU has restored full synchronization, or may indicate that one or more aspects of synchronization have been restored. In one or more cases, the acknowledgement may not refer to aspects of resynchronization, but can indicate that the WTRU can send and receive data from the serving satellite. In one or more other cases, the acknowledgement can be implicit, e.g., based on the success of a WTRU transmission to the serving satellite at some opportunity after the same PCI satellite handover.

[0187] In one or more cases, the WTRU can send an indication, for example, but not limited to, via MAC CE, RRC signaling, UCI, RACH signaling (MSA, MSG3, MSG5), and / or PUSCH transmission. The WTRU may be provided with dedicated resources (e.g., UL grant, dedicated RACH preamble, specific RNTI) to indicate that resynchronization has been successful, and when transmissions are received using the dedicated resources, the network can assume that resynchronization has been successful. The WTRU may include additional assistance information related to one or more resynchronization procedures. The additional assistance information may include one or more of timing advance, power information, measurement results, and / or beam information (e.g., as described herein).

[0188] In one or more cases, after the same PCI satellite handover on a HARQ process configured with reliability (e.g., on a HARQ process configured in HARQ mode A), the WTRU can send a first transmission to the incoming satellite. In some cases, the WTRU can expect that the first reception from the incoming satellite will be received on a HARQ process configured with HARQ feedback.

[0189] In one or more cases, the WTRU may be configured with a declaration of resynchronization failure. If the WTRU is unable to complete resynchronization to the incoming satellite, the WTRU can declare "resynchronization failure". For example, if the WTRU does not recover one or more aspects of synchronization (e.g., time, frequency, power, measurement values) by the end of the resynchronization gap duration (or some other expiration time), the WTRU can declare resynchronization failure. In another example, if the WTRU has a scheduled DL reception or UL transmission to the incoming satellite (e.g., after the resynchronization gap) that it cannot perform because it has not completed resynchronization, the WTRU can declare resynchronization failure.

[0190] The WTRU can declare resynchronization failure before same-PCI satellite handover. For example, if the WTRU is unable to receive the information necessary to perform resynchronization to the incoming satellite, the WTRU can declare resynchronization failure before same-PCI satellite handover. In another example, if the connection with the previous satellite is still in progress, the WTRU can report a resynchronization failure that includes one or more procedures that the WTRU cannot complete and / or information that the WTRU cannot obtain before same-PCI satellite handover.

[0191] In one or more cases, the WTRU can declare partial resynchronization failure if one or more aspects of resynchronization are unsuccessful. In the case of partial resynchronization failure, the WTRU can still resume RX / TX to the incoming satellite but has a sub-optimal configuration (e.g., incorrect power). The WTRU can indicate that one or more aspects cannot be completed or can request the information necessary to resolve the problem.

[0192] When resynchronization failure (or partial resynchronization failure) is declared, the WTRU can perform one or more recovery operations. The one or more recovery operations can include, for example, but are not limited to, beam failure recovery (BFR), radio link failure (RLF), timing advance pre-compensation, conditional handover, cell reselection, random access, applying an alternative measurement configuration, resuming measurement reporting, and / or transitioning to RRC_INACTIVE / IDLE.

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

Claims

1. 1. A wireless transmit / receive unit (WTRU), comprising: a processor, the processor comprising: receiving configuration information indicating a time of a same Physical Cell Identity (PCI) satellite switchover from a first satellite to a second satellite, wherein the configuration information includes an indication of a start time and an indication of an end time for the same PCI satellite switchover from the first satellite to the second satellite; performing the same PCI satellite switch to the second satellite based on the configuration information indicating the time of the same PCI satellite switch.

2. The WTRU of claim 1 , wherein the configuration information is received via broadcast signaling.

3. 3. The WTRU of claim 1 or 2, wherein the processor is further configured to initiate a resynchronization gap in response to the same PCI satellite switch.

4. 4. The WTRU of claim 1, wherein the processor is further configured to discontinue uplink transmission with the first satellite in response to the same PCI satellite switch.

5. The WTRU of claim 1 , wherein the processor is further configured to perform one or more resynchronization procedures in response to the same PCI satellite switch.

6. 6. The WTRU of claim 5, wherein the one or more resynchronization procedures include a timing advance calculation, a Doppler compensation, a power control procedure, or a measurement procedure.

7. 3. The WTRU of claim 1, wherein the processor is further configured to, in response to the same PCI satellite switch, initiate a resynchronization gap, suspend uplink transmission and downlink reception, and perform one or more resynchronization procedures, the one or more resynchronization procedures including timing advance calculation, Doppler compensation, a power control procedure, and a measurement procedure.

8. The processor, 8. The WTRU of claim 1, further configured to: transmit assistance information related to a resynchronization time to assist in measurement gap configuration, the assistance information including a resynchronization duration, an indication that the WTRU may perform a synchronization procedure before the same PCI satellite switch, and an indication of a time that the WTRU may resume communication with the second satellite after the same PCI satellite switch.

9. 9. The WTRU of claim 1, wherein the processor is further configured to receive a configuration for satellite resynchronization with the second satellite, the configuration for satellite resynchronization including a resynchronization gap configuration, a condition for declaring a resynchronization failure, or a resource for indicating successful resynchronization to the second satellite.

10. The WTRU of claim 1 , wherein the processor is further configured to transmit a resynchronization success indication in response to successfully resynchronizing to the second satellite.

11. 1. A method implemented in a wireless transmit / receive unit (WTRU) for transmission processing during same physical cell identity (PCI) satellite switching, comprising: receiving configuration information indicating a time of a same-PCI satellite switchover from a first satellite to a second satellite, the configuration information including an indication of a start time and an indication of an end time for the same-PCI satellite switchover from the first satellite to the second satellite; performing the same PCI satellite switch to the second satellite based on the configuration information indicating the time of the same PCI satellite switch.

12. The method of claim 11 , wherein the configuration information is received via broadcast signaling.

13. 13. The method of claim 11 or 12, further comprising initiating a resynchronization gap in response to the same PCI satellite switch.

14. 14. The method of claim 11, further comprising the step of interrupting uplink transmission with the first satellite in response to the same PCI satellite switch.

15. 15. The method of claim 11, further comprising the step of performing one or more resynchronization procedures in response to the same PCI satellite switch.

16. The method of claim 15 , wherein the one or more resynchronization procedures include a timing advance calculation, a Doppler compensation, a power control procedure, or a measurement procedure.

17. 13. The method of claim 11 or 12, further comprising the steps of initiating a resynchronization gap in response to the same PCI satellite switch, suspending uplink transmission and downlink reception, and performing one or more resynchronization procedures, the one or more resynchronization procedures including a timing advance calculation, a Doppler compensation, a power control procedure, and a measurement procedure.

18. 18. The method of claim 11, further comprising the step of transmitting assistance information related to a resynchronization time to assist in measurement gap configuration, the assistance information including a resynchronization duration, an indication that the WTRU may perform a synchronization procedure before the same PCI satellite switch, and an indication of a time that the WTRU may resume communication with the second satellite after the same PCI satellite switch.

19. 19. The method of claim 11, further comprising receiving a configuration for satellite resynchronization with the second satellite, the configuration for satellite resynchronization including a resynchronization gap configuration, a condition for declaring a resynchronization failure, or a resource for indicating successful resynchronization to the second satellite.

20. 20. The method of claim 11, further comprising the step of transmitting a resynchronization success indication in response to successfully resynchronizing to the second satellite.

Images