Transmission handling for pci satellite handover

Abstract

A Wireless Transmit / Receive Unit (WTRU) may include a processor. The processor may be configured (e.g., via broadcast) to receive configuration information indicating the time at which a handover to the same PCI satellite may occur. In one or more examples, the WTRU may transmit auxiliary information prior to the same PCI satellite handover. The auxiliary information may include, for example, a resynchronization duration, the capability of the synchronization process, and / or a time indication for resuming TX and / or RX. The WTRU may receive configuration information for satellite resynchronization. The WTRU may, for example, perform the same PCI satellite handover to a second satellite based on the configuration information indicating the time for the same PCI satellite handover. During the same PCI satellite handover, the WTRU may initiate a resynchronization gap, suspend UL TX and / or DL ​​RX, and / or perform a resynchronization process (one or more).

Description

[0001] This application is a divisional application of patent application No. 202480033482.2, filed on April 4, 2024, entitled "Transmission Processing for PCI Satellite Handover". Cross-reference to related applications

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 456,866, filed April 4, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0003] WTRUs can be configured for use with non-terrestrial networks (NTNs). NTNs can facilitate the deployment of wireless networks in areas where terrestrial antennas may be impractical and / or undesirable. For example, terrestrial antennas may be impractical due to geography and / or cost. Coupled with terrestrial networks, NTNs can provide ubiquitous 5G network coverage. Some exemplary NTN deployments can support basic calls and text messaging worldwide. With the proliferation of next-generation low-Earth orbit satellites, NTN deployments can enable even more services (e.g., web browsing).

[0004] NTN can include airborne or space-based platforms that can transmit signals from a terrestrial gNB to a WTRU and vice versa via a gateway (GW). An exemplary NTN deployment can support a power-level 3 WTRU with an omnidirectional antenna and linear polarization, or a small-aperture antenna (VSAT) terminal with a directional antenna and circular polarization. An exemplary NTN can provide support for LTE-based narrowband IoT (NB-IoT) and eMTC type devices. In the example, regardless of the device type, the NTN WTRU can have GNSS capability. Summary of the Invention

[0005] The Wireless Transmit / Receive Unit (WTRU) may include a processor configured to receive configuration information indicating the timing for a same Physical Cell Identifier (PCI) satellite handover from a first satellite to a second satellite. The configuration information may include indications of the start and end times for the same PCI satellite handover from the first satellite to the second satellite. The processor may also be configured to receive configuration for satellite resynchronization with the second satellite. The processor may further be configured to perform the same PCI satellite handover to the second satellite based on the configuration information indicating the timing for the same PCI satellite handover.

[0006] Configuration information can be received via broadcast signaling. The processor can also be configured to initiate a resynchronization gap in response to a handover with the same PCI satellite. The processor can also be configured to suspend uplink transmission with the first satellite in response to the handover with the same PCI satellite. The processor can also be configured to perform one or more resynchronization procedures in response to a handover with the same PCI satellite. The processor can be further configured to transmit a resynchronization success indication in response to successful resynchronization with the second satellite.

[0007] One or more resynchronization procedures may include timing advance calculation, Doppler compensation, power control procedures, and / or measurement procedures. In response to a handover of an identical PCI satellite, the processor may be further configured to initiate a resynchronization gap, suspend uplink transmission and downlink reception, and execute one or more resynchronization procedures. The resynchronization procedures may include timing advance calculation, Doppler compensation, power control procedures, and / or measurement procedures. Configuration for satellite resynchronization may include resynchronization gap configuration, conditions for declaring resynchronization failure, and / or resources for indicating successful resynchronization with a second satellite.

[0008] The processor may be further configured to transmit auxiliary information related to the resynchronization time for assisting in the configuration of the measurement gap. The auxiliary information may include the resynchronization duration, an indication that the WTRU can perform the synchronization process before the same PCI satellite handover, and / or an indication of the time when the WTRU can resume communication with the second satellite after the same PCI satellite handover. Attached Figure Description

[0009] Figure 1A This is a system diagram illustrating an exemplary communication system that can implement one or more of the disclosed embodiments.

[0010] Figure 1B It is shown that, according to the embodiment, it is possible to Figure 1A A system diagram of an exemplary wireless transmit / receive unit (WTRU) used within the communication system shown.

[0011] Figure 1C It is shown that, according to the embodiment, it is possible to Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within a communication system.

[0012] Figure 1D It is shown that, according to the embodiment, it is possible to Figure 1A The system diagram shows another exemplary RAN and another exemplary CN used within the communication system shown.

[0013] Figure 2 An exemplary interface in a non-terrestrial network is shown.

[0014] Figure 3 An example is shown where two satellites serve the same PCI.

[0015] Figure 4 This is a flowchart illustrating the pre-calculation of timings and reporting to incoming satellites during the same PCI satellite handover.

[0016] Figure 5 This is a flowchart illustrating an exemplary radio link monitoring process during the same PCI satellite handover.

[0017] Figure 6 This is a flowchart illustrating an exemplary transmission processing and measurement gap configuration during the same PCI satellite handover.

[0018] Figure 7 This is a flowchart illustrating an exemplary power control during the same PCI satellite handover.

[0019] Figure 8 This is a flowchart illustrating an example of beam management during the same PCI satellite handover. Detailed Implementation

[0020] Figure 1A This diagram illustrates an example 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, broadcasting, etc., to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources, including wireless bandwidth. For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT-UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0021] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it should be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Any of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or MiFi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of the wireless transmit / receive units 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs. Furthermore, any descriptions of UEs cited herein are equally applicable to WTRUs (and vice versa). For example, the WTRU can be configured to execute any flow or procedure described herein as being executed by the UE (and vice versa).

[0022] The communication system 100 may also include base station 114a and / or base station 114b. Each of base stations 114a and 114b can be any type of device configured to wirelessly connect to at least one of WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks, such as CN 106 / 115, Internet 110, and / or other networks 112. As an example, base stations 114a and 114b may be base transceiver stations (BTS), NodeBs, eNodeBs, home NodeBs, home eNodeBs, gNBs, NRNodeBs, site controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are each depicted as a single element, it will be understood that base stations 114a and 114b may include any number of interconnected base stations and / or network elements.

[0023] 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 base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, 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 use multiple transceivers for each sector of the cell. For example, beamforming may be used to transmit and / or receive signals in a desired spatial direction.

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

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

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

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

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

[0029] In other embodiments, base station 114a and wireless transmission / reception units 102a, 102b, 102c may implement wireless technologies such as IEEE 802.11 (i.e., Wi-Fi), IEEE 802.16 (i.e., Global Microwave Access Interoperability (WiMAX)), CDMA 2000, CDMA 2000 1X, CDMA 2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSM EDGE (GERAN), etc.

[0030] Figure 1ABase station 114b can be, for example, a wireless router, a home NodeB, a home eNodeB, or an access point, and can utilize any suitable RAT to facilitate wireless connectivity in a local area such as a business premises, home, vehicle, campus, industrial facility, air corridor (e.g., for drone use), road, etc. In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRUs 102c, 102d can implement radio technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, base station 114b and WTRUs 102c, 102d can utilize cellular-based RATs (e.g., WCDMA, CDMA 2000, GSM, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to Internet 110. Therefore, base station 114b does not need to access Internet 110 via CN 106 / 115.

[0031] RAN 104 / 113 can communicate with CN 106 / 115, which can be any type of network configured to provide voice, data, application, and / or Voice over Internet Protocol (VoIP) services to one or more of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, location-based services, prepaid calling, internet connectivity, video distribution, etc., and / or perform advanced security functions (such as user authentication). Although in Figure 1A Although not shown, it should be understood that RAN 104 / 113 and / or CN 106 / 115 can communicate directly or indirectly with other RANs using the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which can utilize NR radio technology, CN 106 / 115 can also communicate with another RAN (not shown) using GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0032] CN 106 / 115 can also be used as a gateway for WTRU 102a, 102b, 102c, 102d to access PSTN 108, the Internet 110, and / or other networks 112. PSTN 108 may include a circuit-switched telephone network providing Common Old-Style Telephone Service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols, such as Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and / or Internet Protocol (IP) from the TCP / IP Internet Protocol suite. Network 112 may include wired and / or wireless communication networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs, which may use the same RAT as RAN 104 / 113 or a different RAT.

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

[0034] Figure 1B This is a system diagram illustrating example WTRU 102. (See diagram below.) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a Global Positioning System (GPS) chipset 136, and / or other peripheral devices 138, etc. It is understood that WTRU 102 may include any sub-combination of the foregoing elements while remaining consistent with the embodiments.

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

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

[0037] Although the transmitting / receiving element 122 is in Figure 1B While described as a single element, WTRU 102 may include any number of transmitting / receiving elements 122. More specifically, WTRU 102 may use MIMO technology. Therefore, in one embodiment, WTRU 102 may include two or more transmitting / receiving elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals via air interface 116.

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

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

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

[0041] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) about the current location of the WTRU 102. In addition to, or alternatively to, the information from the GPS chipset 136, the WTRU 102 may receive location information from base stations (e.g., base stations 114a, 114b) via the air interface 116, and / or determine its location based on the timing of signals received from two or more neighboring base stations. It should be understood that the WTRU 102 may acquire location information using any suitable location determination method, while remaining consistent with the embodiments.

[0042] The processor 118 may also be coupled to other peripheral devices 138, which may include one or more software and / or hardware modules providing additional features, functions, and / or wired or wireless connectivity. For example, peripheral devices 138 may include accelerometers, electronic compasses, satellite transceivers, digital cameras (for photos and / or video), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, FM radio units, digital music players, media players, video game player modules, internet browsers, virtual reality and / or augmented reality (VR / AR) devices, activity trackers, etc. Peripheral devices 138 may include one or more sensors, which may be one or more of the following: gyroscopes, accelerometers, Hall effect sensors, magnetometers, orientation sensors, proximity sensors, temperature sensors, time sensors; geolocation sensors; altimeters, light sensors, touch sensors, magnetometers, barometers, gesture sensors, biometric sensors, and / or humidity sensors.

[0043] WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with specific subframes for uplink (e.g., for transmission) and downlink (e.g., for reception)) may be concurrent and / or simultaneous. The full-duplex radio may include an interference management unit 139 to reduce and / or substantially eliminate self-interference through hardware (e.g., chokes) or through signal processing by a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., signals associated with specific subframes for uplink (e.g., for transmission) or downlink (e.g., for reception)) may occur.

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

[0045] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it should be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. eNode-Bs 160a, 160b, and 160c may each include one or more transceivers to communicate with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, eNode-Bs 160a, 160b, and 160c may implement MIMO technology. Therefore, for example, eNode-B 160a may use multiple antennas to transmit and / or receive radio signals from WTRU 102a.

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

[0047] Figure 1C The CN 106 shown may include a Mobility Management Entity (MME) 162, a Serving Gateway (SGW) 164, and a Packet Data Network (PDN) Gateway (or PGW) 166. While each of the foregoing elements is depicted as part of CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0048] The MME 162 can connect to each of the eNodes B162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, bearer activation / deactivation, selecting a specific serving gateway during the initial attachment of WTRUs 102a, 102b, and 102c, etc. The MME 162 can provide control plane functions for handover between RAN 104 and other RANs (not shown) employing other radio technologies (such as GSM and / or WCDMA).

[0049] The SGW 164 can connect to each of the eNode-Bs 160a, 160b, and 160c in RAN 104 via the S1 interface. The SGW 164 can typically route and forward user data packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can perform other functions, such as anchoring the user plane during handover between eNode Bs, triggering paging when DL data is available to WTRUs 102a, 102B, and 102c, managing and storing the context of WTRUs 102a, 102B, and 102c, etc.

[0050] The SGW 164 can connect to the PGW 166, which can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0051] CN 106 can facilitate communication with other networks. For example, CN 106 can provide WTRU 102a, 102b, and 102c with access to a circuit-switched network (e.g., PSTN 108) to facilitate communication between WTRU 102a, 102b, and 102c and traditional landline communication equipment. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) or can communicate with an IP gateway that serves as an interface between CN 106 and PSTN 108. Furthermore, CN 106 can provide WTRU 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0052] Although WTRU is Figure 1A-1D While described as a wireless terminal, it is conceivable that in some representative embodiments, such a terminal may use a wired communication interface with a communication network (e.g., temporary or permanent).

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

[0054] A WLAN in Infrastructure Basic Services Set (BSS) mode can have an Access Point (AP) for the BSS and one or more Stations (STAs) associated with the AP. The AP can access or connect to a Distribution System (DS) or another type of wired / wireless network carrying traffic entering and / or leaving the BSS. Traffic originating outside the BSS destined for a STA can be delivered to the STA via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. This peer-to-peer traffic can be sent between the source and destination STAs (e.g., directly between the source and destination STAs) using Direct Link Establishment (DLS). In some representative embodiments, the DLS can use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using the Standalone BSS (IBSS) mode cannot have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

[0055] When using 802.11ac infrastructure operating mode or a similar operating mode, the AP can transmit beacons on a fixed channel, such as the primary channel. The primary channel can be of fixed width (e.g., a bandwidth of 20 MHz) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, Carrier Sense Multiple Access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, STAs including the AP (e.g., each STA) can listen on the primary channel. If the primary channel is listened to / detected and / or determined to be busy by a particular STA, that particular STA can back off. A single STA (e.g., only one station) can transmit at any given time within a given BSS.

[0056] High-throughput (HT) STAs can communicate using a 40 MHz wide channel, for example, by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0057] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining 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; this can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel coding, the data can pass through a segmented parser that divides the data into two streams. Each stream can be processed separately using Inverse Fast Fourier Transform (IFFT) and time-domain processing. The streams can be mapped onto the two 80 MHz channels, and the data can be transmitted by the transmitting STA. At the receiver of the receiving STA, the operation of the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0058] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV whitespace (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah can support instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities including support for certain and / or limited bandwidths (e.g., only support). MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0059] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can 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 limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier Sense and / or Network Assignment Vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, because an STA (which only supports the 1 MHz operating mode) is transmitting to the AP, the entire available band can be considered busy even if most of the band remains idle and available.

[0060] In the United States, the available frequency bands for 802.11ah are from 902 MHz to 928 MHz. In South Korea, the available frequency bands are from 917.5 MHz to 923.5 MHz. In Japan, the available frequency bands are from 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.

[0061] Figure 1D This is a system diagram illustrating RAN 113 and CN 115 according to an embodiment. As described above, RAN 113 can communicate with WTRUs 102a, 102b, and 102c via air interface 116 using NR wireless technology. RAN 113 can also communicate with CN 115.

[0062] RAN 113 may include gNBs 180a, 180b, and 180c; however, it should be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. Each of gNBs 180a, 180b, and 180c includes 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 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c may implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to WTRU 102a (not shown). A subset of these component carriers may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In one embodiment, gNBs 180a, 180b, and 180c may implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a may receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0063] WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using transmissions associated with Scalable Digital Numerology (SDN). For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes or Transmission Time Intervals (TTIs) of varying lengths or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying lengths of absolute time).

[0064] gNBs 180a, 180b, and 180c can be configured to communicate with WTRUs 102a, 102b, and 102c in standalone and / or non-standalone configurations. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c without needing to access other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can utilize one or more of gNBs 180a, 180b, and 180c as mobility anchors. In standalone configuration, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using signals in unlicensed frequency bands. In a non-standalone configuration, WTRUs 102a, 102b, and 102c can communicate / connect with gNBs 180a, 180b, and 180c, and also with another RAN (such as eNode-Bs 160a, 160b, and 160c). For example, WTRUs 102a, 102b, and 102c can implement DC principles to communicate essentially simultaneously with one or more gNBs 180a, 180b, and 180c, as well as one or more eNode-Bs 160a, 160b, and 160c. In a non-standalone configuration, eNode-Bs 160a, 160b, and 160c can serve as mobility anchors for WTRUs 102a, 102b, and 102c, while gNBs 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRUs 102a, 102b, and 102c.

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

[0066] Figure 1DThe CN 115 shown may include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and may include data networks (DN) 185a, 185b. While each of the foregoing elements is depicted as part of the CN 115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0067] AMF 182a and 182b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N2 interface and can act as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slicing (e.g., handling different PDU sessions with different needs), selecting specific SMF 183a and 183b, managing registration areas, terminating NAS signaling, mobility management, and so on. AMF 182a and 182b can use network slicing to customize CN support for WTRU 102a, 102b, and 102c based on the type of service being used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for handover between RAN 113 and other RANs (not shown) that employ other radio technologies (such as LTE, LTE-A, LTE-A Pro and / or non-3GPP access technologies (such as WiFi)).

[0068] SMFs 183a and 183b can connect to AMFs 182a and 182b in CN 115 via the N11 interface. SMFs 183a and 183b can also connect to UPFs 184a and 184b in CN 115 via the N4 interface. SMFs 183a and 183b can select and control UPFs 184a and 184b, and configure them to route traffic through UPFs 184a and 184b. SMFs 183a and 183b can perform other functions, such as managing and allocating WTRU IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types can be IP-based, non-IP-based, Ethernet-based, etc.

[0069] UPF 184a and 184b can connect to one or more of gNB 180a, 180b, and 180c in RAN 113 via the N3 interface. The N3 interface can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as Internet 110) to facilitate communication between WTRU 102a, 102b, and 102c and IP-enabled devices. UPF 184 and 184b can 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.

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

[0071] Given Figure 1A-1D and Figure 1A-1D As described herein, one or more of the functions described with respect to one or more of the following can be performed by one or more emulation devices (not shown): WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-b, UPF184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein. An emulation device can be one or more devices configured to emulate one or more of the functions described herein. For example, an emulation device can be used to test other devices and / or simulate network and / or WTRU functions.

[0072] Simulation devices can be designed to perform one or more tests on other devices in laboratory and / or carrier network environments. For example, one or more simulation devices may perform one or more 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. The one or more simulation devices may perform one or more or all functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices may be directly coupled to another device for testing purposes and / or may use over-the-air wireless communication to perform tests.

[0073] One or more simulation devices can perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, simulation devices can be used in test scenarios within a test laboratory and / or an undeployed (e.g., tested) wired and / or wireless communication network to perform testing of one or more components. One or more simulation devices can be test equipment. Simulation devices can transmit and / or receive data using direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas).

[0074] This document uses the following abbreviations and acronyms (including but not limited to): Acknowledgment (ACK); Block Error Rate (BLER); Bandwidth Partial (BWP); Channel Access Priority (CAP); Channel Access Priority Class (CAPC); Idle Channel Assessment (CCA); Control Channel Element (CCE); Control Element (CE); Configured License or Cell Group (CG); Cyclic Prefix (CP); (Cyclic Prefix Dependent) Conventional OFDM (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 Allocation 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 Assisted Access (eLAA); Further Enhanced Licensed Assisted Access (FeLAA); Hybrid Automatic Repeat Request (HARQ); Licensed Assisted Access (LAA); Talk-After-Listen (LBT); Long Term Evolution (LTE), e.g., derived from 3GPP LTE R8 and later versions; Probability of Line of Sight Indication (LOSPI); Negative Acknowledgment (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); Procedure ID (PID); Paging Opportunity (PO); Physical Random Access Channel (PRACH); Master 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 Timing (RO); Radio Resource Control (RRC); Radio Resource Management (RRM); Reference Signal (RS); Reference Signal Received Power (RSRP); Received Signal Strength Indicator (RSSI); Serving Data Unit (SDU); Sound Reference Signal (SRS); Synchronization Signal (SS); Secondary Synchronization Signal (SSS); (in self-contained subframes) Handover Gap (SWG); Semi-Static Scheduling (SPS); Secondary Uplink (SUL); Transport Block (TB); Transport Block Size (TBS); Transmit / Receive Point (TRP); Time-Sensitive Communication (TSC); Time-Sensitive Networking (TSN); Uplink (UL); Ultra-Reliable Low-Latency Communication (URLLC); Wide Bandwidth Component (WBWP).

[0075] The WTRU can support synchronization during same-Physical Cell Identifier (PCI) satellite handover. In one or more cases, the WTRU can receive auxiliary information regarding same-PCI satellite handover (e.g., via broadcast signaling). This information may include timing information and / or satellite entry location information at the time of same-PCI satellite handover. The WTRU can pre-calculate timing advance based on the future location of the satellite entering during same-PCI satellite handover. The WTRU can pre-report future TA values ​​at the indicated offset time prior to satellite handover. The WTRU can reset the L3 measurement window during satellite handover and can apply a measurement configuration. The measurement configuration can be pre-configured. Pre-configured measurement configurations may include, for example, but not limited to, denser measurement objects. The WTRU can apply the pre-configured measurement configuration and filter the coefficients to assess new channel conditions.

[0076] WTRU can provide capabilities and / or auxiliary information about resynchronization time, such as configuration for auxiliary gap measurements. In the example, WTRU can ignore pre-configured scheduling (e.g., CG, periodic SRS, etc.) during resynchronization time.

[0077] The WTRU can scale the power used for the initial UL transfer to the incoming satellite. The WTRU can scale the power used for the initial UL transfer based on the distance difference between the WTRU and the preceding and incoming satellites. In one or more cases, power scaling can be enabled based on configuration / instructions in the System Information Block (SIB). Additionally or alternatively, power scaling can be based on line-of-sight probability (e.g., LOSPI% > X).

[0078] The WTRU can measure reference signals from incoming satellites to determine how to redirect space filters when a new satellite takes over coverage. For example, the WTRU can measure reference signals from incoming satellites (e.g., from one or more SSB / CSI-RS from neighboring cells). In one or more cases, the WTRU receives indications / configurations of reference signals where a first reference signal in a first time period (e.g., before handover) and a second reference signal in a second time period (e.g., after handover) are QCL-compliant to link measurements between the cells(s) originating from the satellite.

[0079] In one or more cases, the WTRU may optionally (e.g., via SR, via pre-configured resources, using the earliest available CG resource, etc.) send an ACK to the incoming satellite to confirm that synchronization has been regained. For example, the WTRU may optionally send an ACK via one or more of SR, pre-configured resources, using the earliest available CG resource, etc.

[0080] WTRUs can be configured for non-terrestrial networks (NTNs). NTNs can facilitate the deployment of wireless networks in areas where terrestrial antennas may be impractical and / or undesirable. For example, terrestrial antennas may be impractical due to geography and / or cost. Coupled with terrestrial networks, NTNs can provide ubiquitous 5G network coverage. Some exemplary NTN deployments can support basic calls and text messaging worldwide. With the proliferation of next-generation low-Earth orbit satellites, NTN deployments can enable even more services (e.g., web browsing).

[0081] NTN can include airborne or space-based platforms that can transmit signals from a terrestrial gNB to a WTRU and vice versa via a gateway (GW). An exemplary NTN deployment can support a power-level 3 WTRU with an omnidirectional antenna and linear polarization, or a small-aperture antenna (VSAT) terminal with a directional antenna and circular polarization. An exemplary NTN can provide support for LTE-based narrowband IoT (NB-IoT) and eMTC type devices. In the example, regardless of the device type, the NTN WTRU can have GNSS capability.

[0082] Airborne or space-based platforms can be classified according to their orbits. In some implementations, Low Earth Orbit (LEO) satellites can operate in an altitude range of 300–1500 km, and Geostationary Orbit (GEO) satellites can operate in an altitude range of 35–786 km. Additional platform classifications can also be supported, or alternatively. For example, Medium Earth Orbit (MEO) satellites operating in an altitude range of 7000–25000 km, and High Altitude Platform Stations (HAPS) permitted in an altitude range of 8–50 km, can be supported. Satellite platforms can be further classified as having “transparent” or “regenerative” payloads. Transparent satellite payloads can perform frequency conversion and RF amplification in both UL and DL. In some implementations, multiple transparent satellites can be connected to a single ground-based gNB. In some examples, regenerative satellite payloads can utilize a complete gNB or gNB DU onboard the satellite. Regenerative payloads can perform digital processing on signals, including, for example, demodulation, decoding, re-encoding, remodulation, and / or filtering.

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

[0084] For example, depending on the satellite payload configuration, various communication interfaces (e.g., 3GPP) can be used for each radio link. For instance, in a transparent payload, the NR-Uu radio interface can be used for serving link 206 and feeder links 202a and 202b. In the example, for a regenerative payload, the NR-Uu interface can be used for serving link 206, while the Satellite Radio Interface (SRI) can be used for feeder links 202a and 202b. In some implementations, ISL may not be used. In the example, a UP / CP protocol stack may exist for transparent payload configuration.

[0085] NTN satellites can support multiple cells, each comprising one or more satellite beams. These beams can cover ground areas (e.g., like terrestrial cells). The diameter of the satellite beams can vary (e.g., 100–1000 km in LEO deployments, 200–3500 km in GEO deployments). In GEO deployments, the beam coverage area can remain fixed relative to the Earth. For LEO deployments, the area covered by the beam / cell may change over time due to satellite movement. In one example, beam movement can be categorized as “Earth movement,” where the LEO beam can move continuously across the Earth's surface. In another example, beam movement can be categorized as “quasi-terrestrial fixed,” where the beam can be manipulated to maintain a fixed coverage position until a new cell takes over the coverage area in discrete and coordinated handovers.

[0086] For example, based on the altitude and / or beam diameter of the NTN platform, the round-trip time (RTT) and / or maximum differential delay can be greater than those of a terrestrial system. 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 the example, the RTT of a regenerative payload can be approximately half that of a transparent payload. For example, the RTT of a regenerative payload can be approximately half that of a transparent payload because a transparent configuration can consider both the serving and feeder links, while the RTT of a regenerative payload can only consider the serving link. To minimize the impact on existing NR systems (e.g., to avoid preamble ambiguity or appropriate timing of the receive window), the WTRU can perform timing pre-compensation before initial access.

[0087] In one or more cases, the WTRU can be configured with user plane enhancements. The pre-compensation process can instruct the WTRU to obtain its position via GNSS, and to obtain the feed link (or common) delay and satellite position via satellite ephemeris data. Satellite ephemeris data can be periodically broadcast in system information. In an example, the satellite ephemeris data may include satellite velocity, orientation, and / or speed. The WTRU can estimate the distance to the satellite (and the delay due to that distance). The WTRU can add a feed link delay component to obtain the complete WTRU-gNB RTT. The complete WTRU-gNB RTT can be used for offset timers, receive windows, or timing relationships, including... ra-ResponseWindow , msgb-ReponseWindow and ra- ContentionResolutionTimer The network can perform frequency compensation.

[0088] The WTRU can calculate its specific TA (and consequently, the WTRU-gNB RTT), and example implementations may include a process for reporting the TA estimate to the network via a new MAC CE. In some examples, a Timely Advance Report (TAR) can be triggered if one or more of the following events occur: TAR can be triggered based on instructions from higher layers. If the WTRU has not previously reported a TA value to the current serving cell, it can be triggered based on upper-layer configurations. offsetThresholdTA Trigger TAR. In another example, if configured, if the change between the current information about timing advance and the previous report information about timing advance is equal to or greater than... offsetThresholdTA Then TAR can be triggered.

[0089] In one or more cases, the WTRU can be configured with HARQ and / or DRX enhancements. The WTRU can be semi-statically configured via RRC to apply specific HARQ behavior to a set of HARQ process IDs. This semi-static configuration can be configured per serving cell. Furthermore, it can be configured via optional settings (…). downlinkHARQ-feedbackDisabled and uplinkHARQ-Mode One or both of these can be configured with a semi-static setup for either the UL or DL ​​HARQ process. Regarding downlinkHARQ- feedbackDisabled WTRU can be configured according to the HARQ process ID and indicates whether DL HARQ feedback is enabled or disabled. Regarding... uplinkHARQ-Mode The WTRU can be configured according to the HARQ process ID and instruct the UL HARQ process to use either HARQModeA or HARQModeB. In the example, HARQModeA can be applied to transports that enable UL HARQ retransmission, and HARQModeB can be applied to transports that disable UL HARQ retransmission or blind UL retransmission.

[0090] The WTRU can adapt the DRX timer based on the configured HARQ features of the HARQ process. The DRX can be adapted for both UL and / or DL ​​to adjust the DRX activity time to compensate for additional propagation delays (e.g., if HARQ feedback is enabled) and / or to achieve additional WTRU power savings (e.g., if HARQ feedback is disabled). The WTRU can adjust its operation based on one or more of the following examples. The WTRU can adjust the DRX timer with respect to DL based on one or more of the following examples. For example, if... downlinkHARQ-feedbackDisabled If configured for the serving cell, during DL reception, if HARQ feedback is permitted for the HARQ process, the WTRU can extend the length of the DLHARQ RTT timer via the WTRU-gNB RTT (e.g., propagation delay). downlinkHARQ-feedbackDisabled If configured for the serving cell, WTRU may not start during DL reception if HARQ feedback is disabled for the HARQ process. drx- RetransmissionTimerDL To achieve additional power savings. Regarding DL, if downlinkHARQ- feedbackDisabled If configured for this serving cell, then during DL reception, if no configuration is specified... downlinkHARQ- feedbackDisabled Then WTRU can apply traditional behaviors (e.g., in drx-HARQ-RTT-TimerDL Start after expiration drx-RetransmissionTimerDL ).

[0091] The WTRU can adapt the DRX timer relative to the DL based on one or more of the following examples. For instance, if uplink HARQ mode is configured for the serving cell, the WTRU can extend the length of the DL HARQ RTT timer (i.e., propagation delay) via WTRU-gNB RTT if the HARQ process is configured to HARQModeA during UL transmission. If uplink HARQ mode is configured for the serving cell, the WTRU can not start DRX-RetransmissionTimerDL during UL transmission if the HARQ process is configured to HARQModeB to achieve additional power savings. If uplink hybrid auto-retransmission request mode is configured for the serving cell, the WTRU can apply traditional behavior (e.g., starting DRX-RetransmissionTimeUL after DRX-HARQ-RTT-TimeUL expires) during UL transmission if uplink hybrid auto-retransmission request mode is not configured.

[0092] In one or more cases, the WTRU can be configured with LCP enhancements 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 assigned to the UL authorization. In one or more examples, the WTRU behavior can be based on two optional RRC configurations ( uplinkHARQ-Mode and allowedHARQ- Mode Use ) to specify. uplinkHARQ-Mode The HARQ process ID can be configured as, for example, HARQModeA or HARQModeB. allowedHARQ-Mode It can be configured by logical channel, and the allowed HARQ modes of the HARQ process mapped to that logical channel can be set.

[0093] Upon receiving a new UL authorization, WTRU can determine whether the LCH is configured. allowedHARQ-Mode And / or whether HARQ mode has been configured for the UL-authorized HARQ process. If both are configured, and the LCH is allowed to map to HARQ mode, the restriction can be satisfied, and data from that logical channel can be mapped to UL authorization. If uplinkHARQ-Mode or allowedHARQ-Mode If not configured, WTRU can map the logical channel to any HARQ process.

[0094] In one or more cases, the WTRU can be configured with control plane enhancements. In the example, the enhancement to RRC_CONNECTED adapts mobility and / or measurement procedures to non-terrestrial environments. Modifications to mobility may include additional execution conditions (such as the A4 event) for conditional handover, as well as time / location-based conditions. Location-based events can be defined by condEventD1. A location-based event can be satisfied if the distance between the WTRU and a first reference location (e.g., within the serving cell) is above a threshold and a second reference location (e.g., within a neighboring cell) is below a threshold. Time-based events can be defined by condEventT1. A time-based event can be satisfied if conditional handover execution occurs, for example, between T1 and T2 (where T2 = T1 + duration).

[0095] In the exemplary NTN implementation, time- and location-based triggering conditions can be configured simultaneously with measurement conditions (e.g., A4). Other modifications can be applied to measurements and may include one or more of the following: location-based measurement reporting, measurement timing configuration (SMTC) based on multiple synchronization signal blocks (SSBs), and / or measurement gaps. Location-based measurement reporting can be based on eventD1 and can utilize execution conditions similar to condEventD1. For a given set of cells, multiple SMTCs can be configured for each carrier based on, for example, propagation delay difference, feeder link delay, and / or serving / neighboring cell satellite ephemeris. In the example, the measurement gaps can be configured using the same or similar propagation delay difference calculated for the SMTCs.

[0096] It can be expected that stationary WTRUs will perform mobility functions for LEO deployments. Based on this, enhanced mobility is of particular interest for LEO deployments. Due to satellite movement, stationary WTRUs can be expected to perform mobility functions, for example, approximately once every 7 seconds, depending on the deployment characteristics.

[0097] Enhancements to idle / inactive cell reselection may include new measurement rules. Two key enhancements may be based on the distance between the WTRU and the cell reference point, and on the time during which a quasi-Earth cell can cease service in the current area (e.g., indicated by t-Service). The cell reference point or parameters used to evaluate distance conditions (e.g., t-Service and distance thresholds) may optionally be broadcast in the SIB (e.g., SIB19). SIB19 may be a new system information block carrying NTN-specific information.

[0098] For example, location-based enhancements can enable measurement relaxation when the WTRU is within a distance 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 may be cell reference points that are not the cell center. Based on the fulfillment of certain conditions, the WTRU may not perform measurements for in-frequency cells, NR cells of the same or lower priority, and / or inter-RAT frequency cells of lower priority. For example, the WTRU may not perform the above operations if all of the following conditions are met: the serving cell satisfies Srxlev > SIntraSearchP and Squal > SIntraSearchQ; the WTRU has valid WTRU location information (i.e., the WTRU implementation has available WTRU location information); and the distance between the WTRU and the serving cell reference location is less than the distance threshold (distanceThresh).

[0099] Time-based enhancements can instruct the WTRU to perform cell reselection measurements in a quasi-terrestrial fixed cell at a certain time (e.g., before t-Service), based on the WTRU implementation. In the example, the WTRU can perform in-frequency, inter-frequency, 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. Distance- and time-based measurement rules can remain unaffected by measurements of higher-priority NR inter-frequency and / or inter-RAT frequencies. In the example, the WTRU can perform these measurements regardless of the remaining service time and / or the distance to the cell reference point.

[0100] In one or more examples, WTRU can be configured for IoT NTN. In these examples, NR NTN enhancements can be used for IoT NTN. For example, enhancements may include: time / frequency pre-compensation; advance timing reporting; timer and monitoring window offset; and / or t-Service-based cell (re)selection enhancements. Some implementations may support enhancements such as disabling HARQ feedback and / or mobility enhancements.

[0101] IoT NTN can leverage enhancements relevant to considerations of discontinuous coverage scenarios. Discontinuous coverage in NTN can refer to temporary and / or predictable coverage gaps caused by discontinuous coverage in non-geosynchronous satellite orbit (NGSO) deployments. This might not be a problem if continuous coverage is available globally, but in some NTN implementations, continuous coverage may not be available globally (e.g., early deployments, deployments in deep rural areas). IoT NTN can provide enhancements to address discontinuous coverage scenarios. In some examples, these enhancements may not be available in NR NTN.

[0102] Due to deterministic satellite movement, coverage gaps can be predicted and accounted for. IoT NTN can support additional auxiliary information (e.g., satellite ephemeris and coverage parameters such as coverage area radius, cell reference point, or elevation angle, and / or the service start time of neighboring cells given by t-servicestart) to predict the duration of coverage gaps. When within discontinuous coverage gaps, the WTRU can suspend AS functionality.

[0103] In some implementations, enhancements to NR NTN may exist. For example, NR NTN enhancements may include: coverage enhancements, NR-NTN above 10 GHz, network (NW) verified WTRU locations, and / or NTN-NTN and NTN-TN mobility and / or service continuity. Coverage enhancements may include enhancements to PUCCH for Msg4 HARQ-ACK, DMRS binding for PUSCH (e.g., considering NTN-specific issues), and support for blind MSG3 retransmission license reception. For NR-NTN above 10 GHz, analyses may be performed on, for example, rules and adjacent channel coexistence scenarios, Rx / Tx requirements for satellite access nodes and WTRU levels, and / or physical layer parameter values. Enhancement schemes may exist for network-verified WTRU locations, such as employing multi-RTT support for network-verified WTRU locations. For NTN-NTN and NTN-TN mobility and service continuity, there may be enhancements related to, for example, the following: cell (re)selection for NTN-TN and Earth Mobile cells, handover with reduced signaling overhead, and / or Xn / NG signaling to support feeder link handover.

[0104] In some implementations, enhancements to the IoT NTN may exist. For example, IoT NTN enhancements may include performance enhancements, mobility enhancements, and / or enhancements for discontinuous coverage scenarios. For performance enhancements, this may include supporting the disabling of HARQ feedback and / or improved GNSS operation to provide new positioning results for WTRU pre-compensation during long connectivity periods. For mobility enhancements, this may involve measurement triggering before RLF, signal notification in the system information of neighboring cell ephemeris, adoption of the Rel-17 solution introduced in NR-NTN for mobility enhancements, and / or WTRU RRM core requirements for the listed functions. For discontinuous coverage scenarios, enhancements may include specifying mobility management enhancements and / or power-saving enhancements for discontinuous coverage.

[0105] In one or more scenarios, the WTRU can be configured to synchronize during handover of satellites with the same PCI. In some NTNs, cells originating from different satellites can be associated with different PCIs. When a serving satellite flies over and moves out of coverage (e.g., due to the curvature of the Earth), a stationary WTRU may experience continuous L3 mobility, and a new satellite may take over coverage of that geographic area.

[0106] Figure 3 An exemplary same PCI handover 300 is shown, where satellites 302a and 302b serve the same PCI 304a. In the case of quasi-terrestrial fixed cells, hard handover can occur in the same SSB frequency and the same gNB. In this quasi-terrestrial fixed cell scenario, satellite handover without PCI handover can be supported. PCI handover is illustrated in example 300. The WTRU 310 can support resynchronization to an incoming satellite 302b using the same PCI 304a. The methods and implementations for WTRU resynchronization can reduce downtime during satellite handover and avoid unnecessary radio link failures (RLFs).

[0107] In the exemplary same PCI handover 300, the geographic area is associated with PCIs 304a, 304b, 304c and gNBs 306, 306. At time T0, PCI 304a is served by a first satellite 302a. When the first satellite 302a moves out of coverage (e.g., due to the curvature of the Earth), a second (entering) satellite 302b connected to the same gNB 306 can begin serving PCI 304a. This can occur at a handover point 308 that the network can know in advance. This solution avoids the need for L3 mobility, thereby reducing signaling overhead. However, because the previous satellite 302a and the entering satellite 302b are physically far apart, the WTRU 310 must resynchronize with the new satellite 302b, as radio conditions, timing advance, Doppler compensation, and UL beam direction can be very different. Since the PCI 304a, gNB 306, and SSB frequencies remain the same, satellite handover is largely transparent to the WTRU 310, although the WTRU 310 may require some auxiliary information for resynchronization with the incoming satellite 302b. The WTRU 310 can support resynchronization with the incoming satellite 302b, which serves the same PCI 304a. WTRU resynchronization can reduce downtime during satellite handover and avoid unnecessary RLF (Recurrent Range Failure).

[0108] The WTRU can be configured to perform time synchronization during same-PCI satellite handover. In one or more cases, prior to same-PCI satellite handover, the WTRU can receive configuration for pre-reporting timing advance and auxiliary information for entering the satellite (e.g., the time of same-PCI satellite handover and the location of the entering satellite). The WTRU can receive this configuration to reduce TA resynchronization time and congestion caused by large-scale TA reporting. The WTRU can use the auxiliary information to calculate the timing advance of entering the satellite during same-PCI satellite handover and report the future TA at the configuration offset relative to the satellite handover time. The future TA at the configuration offset relative to the satellite handover time can indicate, for example, the TA value applied to the entering satellite. During satellite handover, the WTRU can apply the pre-calculated TA to subsequent transmissions. If the WTRU has successfully reported the TA to the entering satellite prior to satellite handover, the WTRU can ignore TAR triggering (e.g., due to offsetThreshold TA configuration).

[0109] In some examples, the WTRU can calculate the TA value via ephemeris before RACH. This can lead to TA synchronization failures due to large time differences during handovers of the same PCI satellites (which do not require RACH). Some triggers that rely on TA reporting (e.g., offsetThreshold TA) can result in significant signaling overhead after the handover time. Therefore, to address these system issues, the WTRU can pre-calculate the TA based on the future position of the incoming satellite during handovers of the same PCI satellites. The WTRU can pre-report future TA values, for example, at the indicated offset time before the satellite handover.

[0110] The WTRU can receive (e.g., via broadcast) the time and location of an incoming satellite for a handover to the same PCI satellite. In one or more cases, the WTRU can receive a configuration for pre-reporting TA (pre-TAR) to the new satellite. The WTRU can receive a configuration including one or more of the following: an enable / disable indication for pre-TAR reporting; an offset for reporting the pre-TAR prior to the satellite handover time; a time period for reporting the pre-TAR; and / or conditions for reporting the pre-TAR. Conditions for reporting pre-TAR may include, for example, an incremental threshold relative to the TA for the previous satellite. In one or more cases, the WTRU can pre-calculate the TA value for the incoming satellite using the location of the incoming satellite at the time of the 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 may 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 during a handover to the same PCI satellite. If the WTRU can successfully report future timing advance before satellite handover (e.g., the WTRU receives an ACK for a transmission carrying pre-TAR), the WTRU can ignore the triggering condition if offsetThreshold TA is configured and TAR is triggered due to satellite handover. If the WTRU cannot successfully report future timing advance before satellite handover, the WTRU can transmit TAR using the pre-calculated timing advance during satellite handover. In one or more cases, the WTRU can (e.g., after handover to the same PCI satellite) use the pre-calculated TA to transmit UL TB.

[0111] The WTRU can be configured to perform radio link monitoring (RLM) during same-PCI satellite handover. After same-PCI satellite handover, measurements and / or cell quality information associated with the previous satellite may no longer be valid. To avoid averaging of channel conditions for incoming satellites, the WTRU can reset the L3 measurement window during satellite handover. The WTRU can apply a new measurement configuration (e.g., a temporary configuration with a denser set of measurement objects) and / or L3 filter coefficients to obtain measurement results and resynchronize with the incoming satellite after satellite handover. The WTRU can temporarily suspend L3 event-based reporting before and / or at a certain offset time after satellite handover to avoid unnecessary reporting and mobility. For example, to avoid using resources reporting to cells that are no longer available, the WTRU can temporarily suspend L3 event-based reporting at a certain offset time before satellite handover, as if channel conditions are about to change. Alternatively or additionally, the WTRU can temporarily suspend L3 event-based reporting at a certain offset time to allow time for accurate measurement of new channel conditions.

[0112] In some implementations, the WTRU can perform time-domain averaging of cell measurements to obtain L3 cell quality. This process may delay the detection of radio problems on the new satellite after satellite handover, and the rapid transmission of new measurement results to the incoming satellite may require measurement reconfiguration after the handover. Considering the WTRU-gNB RTT and / or RLF risks, measurement reconfiguration can be time-consuming. In this example, to address the above issues, the WTRU can reset the L3 measurement window during satellite handover and can apply a pre-configured measurement configuration (e.g., with denser measurement objects) and / or filtering coefficients to quickly assess the new channel conditions.

[0113] In one or more cases, the WTRU receives (e.g., via broadcast) the time when the same PCI satellite handover will occur. The WTRU may receive the measurement configuration applied during the same PCI satellite handover. The measurement configuration may include one or more of the following: a temporary measurement configuration; expiration conditions for the temporary measurement configuration (e.g., the number of RSs measured, duration, etc.); a second measurement configuration (e.g., a second measurement configuration applied after the temporary measurement configuration); L3 filter coefficients applied during the satellite handover; and / or a configuration for suspending measurement reporting. Configuration information indicating the suspension of measurement reporting may include, for example, one or both of the start time and duration.

[0114] The WTRU can perform the same PCI satellite handover based on the received configuration. The WTRU can perform one or more of the following actions associated with performing the same PCI satellite handover: suspend measurement reporting (e.g., follow some configured prohibition duration); reset the L3 measurement window (e.g., discard previous serving cell measurements); apply a temporary measurement configuration; and / or apply updated L3 filtering coefficients. In the example, the expiration condition of the temporary measurement configuration may not be met or may not be configured, and the WTRU can perform measurements and filtering based on the updated L3 filtering coefficients according to the temporary measurement configuration. If the expiration condition of the temporary measurement configuration is met, and the WTRU is not provided with a second measurement configuration, the WTRU can revert to the previous measurement configuration (e.g., the configuration used before the satellite handover). The WTRU can transmit measurement reports based on the new measurement configuration.

[0115] The WTRU can be configured for transmission processing during same-PCI satellite handover. The WTRU resynchronization time associated with same-PCI satellite handover can vary based on the WTRU's ability to determine or pre-determine synchronization aspects (e.g., timing advance, power control, etc.). Transmission and / or reception can be suspended during resynchronization. If the network is unaware of the WTRU's resynchronization time, there may be associated risks. For example, there may be risks of additional delays and wasted transmission opportunities (e.g., if the resynchronization time is overestimated), or missed transmit (TX) and / or receive (RX) opportunities (e.g., if the resynchronization time is underestimated). To support resynchronization gap configuration, the WTRU can transmit capability and / or ancillary information (e.g., estimated resynchronization time) prior to satellite handover. During resynchronization, the WTRU can suspend TX and / or RX, including, for example, pre-scheduled transmissions such as configured authorizations, periodic CSI / SRS, etc. In one or more examples, after resynchronization, the WTRU can signal the completion of synchronization (e.g., via transmission of one or more UL signals). Examples of UL signals may include, but are not limited to: SR, CG transmissions, PRACH, HARQ ACK, etc.

[0116] In some implementations, the WTRU may rely on network scheduling and / or periodic configuration for pre-configured transmissions 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 incorrect, resynchronization with a new satellite may result in wasted resources (e.g., overestimation) or missed TX and / or RX (e.g., underestimation). To address these system problems, the WTRU can provide capability and / or auxiliary information regarding resynchronization time for assisting in measurement gap configuration. The WTRU may ignore pre-configured scheduling (e.g., CG, periodic SRS, etc.) during the resynchronization time. Alternatively or additionally, the WTRU may optionally send an ACK to acknowledge that synchronization has been regained. For example, the WTRU may optionally send an ACK via SR, pre-configured resources, using the earliest available CG resource, etc.

[0117] The WTRU can receive (e.g., via broadcast) configuration information indicating the time when a handover to the same PCI satellite will occur. In one or more examples, the WTRU can transmit auxiliary information prior to the handover to the same PCI satellite. The auxiliary information can include, for example, one or more of the following: the resynchronization duration; the WTRU's ability to perform synchronization procedures (e.g., pre-calculation and reporting of timings) prior to the handover to the same PCI satellite; and / or the time at which the WTRU can restore TX and / or RX after the handover to the same PCI satellite. The WTRU can receive configuration information for satellite resynchronization. The configuration for satellite resynchronization can include, for example, one or more of the following: a resynchronization gap configuration; conditions declaring resynchronization failure; and / or resources for indicating successful resynchronization (e.g., UL authorization, dedicated RACH preamble).

[0118] The WTRU can perform a handover to a second PCI satellite, for example, based on configuration information indicating the time for the handover. During the handover, the WTRU can initiate a resynchronization gap, suspend ULTX and / or DL ​​RX, and perform one or more resynchronization procedures (e.g., timing advance calculation, Doppler compensation, power control, measurement) for satellite access. The WTRU can use the received configuration information to initiate the resynchronization gap. If the WTRU is configured to do so, it can transmit an indication of successful resynchronization after successful resynchronization with the satellite (e.g., via provided resources).

[0119] The WTRU can be configured for power control during handover to the same PCI satellite. For example, due to the significant positional difference between the preceding and incoming satellites, the UL TX power required by the WTRU after handover may change significantly. If the WTRU uses too little power, it risks unsuccessful reception. If the WTRU uses too much power, it risks interference and unnecessary power consumption. In this example, line-of-sight (LOS) is likely (e.g., very likely) in an NTN environment. If LOS is present, the largest portion of the path loss is likely due to free-space propagation loss.

[0120] The WTRU can estimate free-space propagation loss based on known information. For example, the WTRU can estimate free-space propagation loss based on known positions of the preceding and approaching satellites (e.g., through auxiliary information). Using the free-space propagation estimate, the WTRU can scale the UL transmission power used for the initial transmission to the approaching satellite based on the incremental distance to the preceding satellite. The UL transmission power can be additionally controlled by NW configuration (e.g., enable / disable, maximum allowed incremental scaling). Furthermore, or alternatively, the UL transmission power can satisfy conditions. For example, the UL transmission power can be based on the line-of-sight probability (LOSPI) for the preceding and / or approaching satellite being higher than a configured threshold.

[0121] In some examples, the WTRU may wait to adjust the UL transmission power after satellite handover until a power control command is received. In such examples, waiting for a power control command to adjust the UL TX power may risk failed transmissions (one or more) (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 the initial UL transmission to the new satellite based on the distance difference between the WTRU, the old satellite, and the new satellite. In examples, the scaled power may be enabled based on configuration and / or indications in the SIB. Additionally or alternatively, the scaled power may depend on the high line-of-sight probability (i.e., LOSPI% > X).

[0122] The WTRU can receive, for example, ancillary information for the preceding and approaching satellites via broadcast. Ancillary information may include one or more of the following: ephemeris data of the currently serving satellite; the time of a handover to a same PCI satellite; and / or the location of the approaching satellite during a handover to a same PCI satellite. In one or more cases, the WTRU can receive configuration information for calculating the UL TX power to the approaching satellite. The configuration for calculating the UL TX power may include one or more of the following: an enable / disable indication; a maximum increment value of the original TX power that can be autonomously adjusted by the WTRU; minimum line-of-sight probability thresholds for the preceding and approaching satellites; and / or a determination of whether (e.g., within a first transmission) an indication of the amount of adjustment the WTRU has made to the UL TX power and / or UL TX power level. In one or more cases, the WTRU can acquire updated WTRU information, for example, via GNSS. The WTRU can calculate the distance to the satellite for each satellite during a handover to a same PCI satellite (e.g., using satellite ancillary information). In one or more cases, the WTRU can calculate the line-of-sight probability for each satellite. In the example, for a handover to the same PCI satellite, if WTRU autonomous UL TX power adjustment is enabled and the line-of-sight conditions for the preceding 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 use the adjusted UL TX power to transmit the initial UL transmission. (E.g., if configured by the network) The WTRU can include incremental adjustments and / or the current UL TX power in the initial transmission. In the example, for a handover to the same PCI satellite, if WTRU autonomous UL TX power adjustment is not enabled and / or the line-of-sight conditions for the preceding and incoming satellites are not met, the WTRU can use the UL TX power used for the transmission to the preceding satellite to transmit the initial UL transmission.

[0123] The WTRU can be configured to perform beam management during the same PCI satellite handover. During the same PCI satellite handover, the serving satellite and the incoming satellite can be located in different positions. Thus, the WTRU can redirect the ULTX beam after the satellite handover. The WTRU can, for example, use reference signals from neighboring cells (e.g., SSB / CSI-RS) to predict how to redirect the WTRU spatial filter, where the reference signals originate from the incoming satellite that will take over the PCI. To support this mapping, the WTRU can receive a first time period (e.g., before the satellite handover) and a second time period (e.g., after the satellite handover) indicating and / or configuring quasi-co-location (QCL) of the reference signals (e.g., originating from the incoming satellite) and a second reference signal (e.g., after the satellite handover). In this way, the WTRU can apply measurements taken before the handover to pre-determine the beam orientation and channel conditions for the incoming satellite after the handover, thereby accelerating resynchronization with the incoming satellite.

[0124] In some examples, the WTRU may wait to determine how to redirect the spatial filter and perform channel measurements until after a satellite handover event, thus increasing resynchronization time. To address this issue in legacy systems, the WTRU can measure reference signals from the incoming satellite (e.g., some SSB / CSI-RS from neighboring cells) to understand how to redirect the spatial filter when the incoming satellite takes over coverage. The WTRU can receive reference signals in a first time period (i.e., before handover) and a second reference signal in a second time period (i.e., after handover) as QCL indications and / or configurations to link measurements before and after handover.

[0125] The WTRU can receive configuration information indicating the handover time of the same PCI satellite (e.g., via broadcast). In one or more cases, the WTRU can receive indications and / or configurations that a reference signal in a first time period (e.g., before the satellite handover) and a second reference signal in a second time period (e.g., after the satellite handover) are QCLs. In an example, the WTRU can measure the reference signal originating from the incoming satellite during the first time period. In one or more cases, the WTRU uses the reference signal from the first time period to calculate the beam direction and DL path loss to the incoming satellite. During the same PCI satellite handover, the WTRU can (e.g., by applying an updated space filter) redirect its UL TX beam and adjust the transmission power for the initial UL transmission based on the mapping configuration and measurements from the reference signal in the first time period (e.g., based on the DL path loss measured in the first time period). In an example, the WTRU can link measurements from the first time period to measurements in the second time period. In the example, the WTRU can use a defined UL TX beam and a transmit power calculated based on the reference signal received power (RSRP) of the reference signal during the first time period to transmit the same PCI satellite handover confirmation (e.g., using MAC CE or a pre-configured PUCCH).

[0126] Note that the term "previous satellite" can refer to a satellite serving the PCI prior to the same PCI satellite handover. Additionally, note that the term "entering satellite" can refer to a satellite serving the PCI after the same PCI satellite handover. Note that the term "temporary measurement configuration" can refer to a measurement configuration applied during or near the same PCI satellite handover to, for example, support rapid resynchronization to the entering satellite. Furthermore, note that the term "resynchronization gap" can refer to a period indicated or configured by the network, where the WTRU is expected to perform one or more aspects of resynchronization with the entering satellite during the same PCI satellite handover. It should also be noted that the term "WTRU autonomous power adjustment" can refer to the WTRU adjusting the UL transmission power for the initial UL transmission for the entering satellite after the same PCI satellite handover.

[0127] The methods and embodiments described herein can be referenced to examples of same PCI satellite handover. However, it should be understood that the embodiments can be applied to other non-terrestrial mobility scenarios, such as, but not limited to: feeder link handover, quasi-terrestrial fixed cell change and / or inter-satellite mobility and / or cell (re)selection (e.g., in a given solution, by replacing "same PCI satellite handover" with one or more of the above scenarios). Additionally, it should be understood that the embodiments can be applied to multi-TRP scenarios (where more than one TRP serves PCI), and resynchronization during RACH-free handovers. Furthermore, the embodiments described herein can support enhanced resynchronization of incoming satellites during same PCI satellite handovers (e.g., faster resynchronization). Thus, the methods and embodiments can reduce service interruption time and / or reduce the risk of RLF due to loss of synchronization. In the examples, these embodiments can allow pre-synchronization, thereby reducing the risk of congestion caused by signaling overhead after satellite handover. Note that the embodiments discussed herein can be combined with one or more of the other embodiments discussed herein.

[0128] The WTRU can be configured with configuration and / or ancillary information to support resynchronization with incoming satellites. To support resynchronization during same-PCI satellite handover, the WTRU can receive ancillary information and / or configuration from the network. For example, ancillary information and / or configuration can be provided via dedicated signaling (e.g., via RRC signaling, MAC CE, or DCI), broadcast in system information, or both. For instance, the WTRU can receive ancillary information (e.g., same-PCI handover time and information related to adjacent satellite positions) broadcast, and the WTRU can receive configuration information for TA calculations, measurement reports, resynchronization gap configuration, power control, and / or beam management in a dedicated manner (e.g., via RRC). In one or more cases, the WTRU can (e.g., through configuration) receive and maintain updated system information prior to same-PCI satellite handover. Receiving and maintaining updated system information prior to same-PCI satellite handover minimizes the risk of resynchronization failure and ensures that necessary information is available during same-PCI satellite handover.

[0129] In some cases, WTRU configuration and / or ancillary information provided in a dedicated manner can override ancillary information received via broadcast instructions. For example, the WTRU may receive one or more of the following ancillary information and / or configurations to support resynchronization during same PCI satellite handover: the handover time of the same PCI satellite (e.g., 10:31:20). UTC time); the location of the incoming satellite during same PCI satellite handover; the location of the preceding satellite during same PCI satellite handover; ephemeris data of the incoming satellite (e.g., supporting WTRU prediction of the incoming satellite location during same PCI satellite handover); ephemeris data of the preceding satellite (e.g., supporting WTRU prediction of the preceding satellite location during same PCI satellite handover); common time information of the incoming satellite and / or the preceding satellite (e.g., feed link delay, kmac, etc.) during same PCI satellite handover; information and / or configurations (one or more) supporting pre-calculation and reporting of timing advance for the incoming satellite; information and / or configurations (one or more) supporting radio link monitoring; information and / or configurations (one or more) for resynchronization gaps and RX / TX pauses; information and / or configurations (one or more) supporting WTRU autonomous UL power adjustment; information and / or configurations (one or more) supporting beam management; information and / or configurations (one or more) supporting resynchronization status indication.

[0130] In one or more examples, the WTRU can be configured to request access satellite auxiliary information during same-PCI satellite handover. The WTRU can request auxiliary information to support resynchronization with the access satellite during same-PCI satellite handover. For example, if the WTRU cannot obtain one or more information fields necessary to complete resynchronization before same-PCI satellite handover, the WTRU can trigger the request. Alternatively or additionally, the WTRU can trigger the request for auxiliary information based on connection establishment (e.g., during initial access, service recovery) or mobility. In one or more cases, the request for auxiliary information can be sent via, for example, UCI, SR, RACH messages (e.g., MSGA, MSG3, MSG5), PUSCH, MAC CE, and / or RRC signaling. The auxiliary information request can include a general request (e.g., a flag indicating a request for all available information). The auxiliary information can indicate one or more specific information fields to be provided to the WTRU.

[0131] The WTRU can be configured for time synchronization during handovers to satellites with the same PCI architecture. Because the incoming satellite and the preceding satellite are physically far apart during a handover to a satellite with the same PCI architecture, the WTRU may experience large timing advance differences when the handover occurs. In an example (e.g., a conventional implementation), the WTRU may calculate the TA value via ephemeris before RACH. Based on this, TA discrepancies may exist during handovers to satellites with the same PCI architecture (e.g., those that may not require RACH), potentially leading to TA synchronization failures. In the example, triggers that rely on existing TA reports (e.g., offsetThresholdTA) may cause congestion after the satellite handover due to signaling overhead, for example, from large-scale TA report triggers.

[0132] The methods and embodiments described herein can reduce TA resynchronization time and / or mitigate congestion risks following satellite handover (e.g., due to large-scale TA reporting). For example, the WTRU can pre-calculate TA values ​​based on the future position of the satellite entering the handover at the same PCI satellite and pre-report future TA values ​​at the indicated offset time prior to the satellite handover.

[0133] In one or more implementations, the WTRU can be configured to pre-calculate timing advance for an incoming satellite. The WTRU can pre-calculate the timing advance (TA) for an incoming satellite for the same PCI satellite handover time. The WTRU can pre-calculate the TA to achieve rapid timing synchronization with the incoming satellite, for example, after the same PCI satellite handover. In an example, the network can control (e.g., enable / disable) the WTRU's ability to pre-calculate the TA via one or more of the following: a configured explicit RRC, an indication in broadcast signaling, and an activation (deactivation) command (e.g., via MAC CE). The network can configure windows (e.g., time periods) and / or offsets relative to the same PCI satellite handover for the WTRU to pre-calculate the TA. If the WTRU cannot determine the future TA by the expiration of the time period or by the indicated time, the WTRU may not pre-calculate the timing advance. If timing advance pre-calculation is enabled and the WTRU cannot perform pre-calculation, the WTRU may send a report or indication to the network.

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

[0135] In one or more cases where timing advance is pre-calculated, the WTRU can be requested and / or triggered to report its position, allowing the network to calculate WTRU timing advance. For example, the WTRU can be requested and / or triggered at an offset time prior to a handover of the same PCI satellite to report its position. In some cases, the WTRU can be requested and / or triggered to report its estimated position during satellite handover. In the example, the network can provide a timing advance command with an associated activation time. The associated activation time could be, for example, a handover of the same PCI satellite. In one or more cases, the WTRU can apply a TA value to a transmission occurring after the activation time.

[0136] If the WTRU has already pre-reported the TA value, the WTRU can receive additional TA adjustments from the network before satellite handover. For example, the network can (e.g., explicitly) indicate whether the TA command is for the current TA (e.g., for the previous satellite) or for a future TA (e.g., for the incoming satellite).

[0137] In one or more cases, the WTRU may be provided with two types of ephemeris information to determine timing advance values. The first type of ephemeris information can be used to determine one or more transmission parameters for the current uplink transmission. This first type of ephemeris information can also be used to determine one or more transmission parameters for a first time window. Transmission parameters may 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. This second type of ephemeris information can also 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 an 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 signaling), and each ephemeris information may be indicated or associated with time information. Time information may include, for example, validity timers, timestamps, validity durations, start / end times, etc.

[0138] WTRUs can report timing advances to incoming satellites. WTRUs can report TAs based on configuration. WTRUs can report pre-calculated TAs to incoming satellites prior to same-PCI satellite handovers. WTRUs can report pre-calculated TAs to incoming satellites to reduce congestion caused by large-scale TARs after same-PCI satellite handovers. WTRU TA pre-reporting (i.e., pre-TAR) can be influenced by configurations that may include one or more of the following: enable / disable indications; offsets relative to the same-PCI handover time for performing the pre-TAR; a window (e.g., a time period) for reporting the pre-TAR; and / or resources for reporting the pre-TAR (e.g., UL scheduling permissions), including information fields (e.g., service link TA and full TA) within the pre-TAR.

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

[0140] For cases where timing advance reporting is enabled and all configured conditions are met, the WTRU can trigger a pre-TAR transmission. 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., a future timing advance value for an incoming satellite during same PCI satellite handover); an absolute TA value corresponding to the full WTRU-gNB timing advance; an absolute TA value for the serving link (e.g., WTRU-entry satellite timing delay); an increment to the currently applied timing advance (e.g., timing advance for a previous satellite); information for pre-calculating the TA (e.g., the location and timing information of the incoming satellite); and / or when the WTRU (e.g., when the WTRU applies the TA value to subsequent UL transmissions) will be estimated by a time-synchronized WTRU.

[0141] In one or more scenarios, the WTRU can be configured to perform one or more actions during same PCI satellite handover. During same PCI satellite handover (or at an explicitly indicated activation time), the WTRU can apply a pre-calculated TA value and use that value for subsequent transmissions. If the WTRU is configured with... offsetThresholdTA If the application of the new TA value triggers a timed advance report (TAR), then if the WTRU has already pre-reported the TA value to the incoming satellite, the WTRU can ignore the TAR trigger. The WTRU can ignore the TAR trigger by not triggering it and not sending an updated report. In one example, the WTRU can ignore the trigger provided it confirms that the pre-reported timed advance value has been successfully received. The WTRU can determine successful reception, for example, based on the reception of HARQ-ACK.

[0142] Figure 4 This is a flowchart illustrating process 400 for pre-calculating timing advance and reporting to incoming satellites during same PCI satellite handover. In one or more cases, prior to satellite handover, the WTRU may receive TA reporting configuration and information about the time and location of neighboring satellites at the time of handover. At 402, the WTRU may receive auxiliary information about the incoming satellite. The auxiliary information received at 402 may include one or more of the following: the time of same PCI satellite handover; the location of the incoming satellite during same PCI satellite handover; and / or the ephemeris data of the incoming satellite. At 404, the WTRU may receive configuration information for pre-reporting the timing advance of incoming satellites. For example, the configuration information received at 404 may include: an enable / disable indication; a reporting time offset relative to the same PCI satellite handover time; a time window for pre-reporting same PCI satellite handover; resources for reporting; and / or conditional thresholds (e.g., incremental time) for enabling pre-reporting.

[0143] At 406, (e.g., if pre-computation is enabled and all configuration conditions are met) the WTRU can pre-computate the timing advance for the incoming satellite during same-PCI satellite handover. If the WTRU is configured to pre-report the timing advance at 408, and the pre-reporting conditions are met at 410, the WTRU can transmit a timing advance report including the TA for the incoming satellite at 412. The WTRU can report a new TA at the configured offset from the transition time. The WTRU can report a new TA at the configured offset from the transition time, which 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 transmits a pre-reported TA at 412, the WTRU can wait for the same-PCI satellite handover time at 414. Upon same-PCI satellite handover determined at 414, the WTRU can apply the pre-computed TA for the new satellite at 416. The WTRU can apply the new timing advance during or during satellite handover. At 418, configuration is possible. OffsetThresholdTA If (for example, determined in 418) OffsetThresholdTA If configured, the WTRU can ignore the triggering of reporting the TA if it has already been pre-reported. For example, at 420, the WTRU can determine that the TA has been successfully pre-reported and ignore the triggering at 422. If the TA is not determined to have been pre-reported at 420, the WTRU can transmit the TAR at 424.

[0144] In the example, the WTRU can perform one or more of the following to support time synchronization during same PCI satellite handovers. For example, the WTRU can receive the time and location of an incoming satellite during a same PCI satellite handover (e.g., via broadcast). The WTRU can receive a configuration for pre-reporting timing advance (pre-TAR) to the new satellite. The configuration for pre-reporting timing advance can include one or more of the following: an enable / disable indication for pre-TAR reporting; an offset of the pre-TAR prior to the satellite handover time for reporting the pre-TAR; a time period for reporting the pre-TAR; and conditions for reporting the pre-TAR (e.g., a timing advance increment threshold relative to the previous satellite). The WTRU can pre-calculate a timing advance value for the incoming satellite using the location of the incoming satellite during the PCI handover. The WTRU can transmit the pre-calculated TA value according to the pre-reporting configuration. In one or more cases, the pre-reporting configuration can explicitly indicate that the TA value is associated with the incoming satellite. The WTRU can apply the pre-calculated timing advance for the incoming satellite during a same PCI satellite handover. If the WTRU successfully reports a future timing advance before satellite handover (e.g., the WTRU receives an ACK for a transmission carrying pre-TAR), the WTRU will, based on its configuration... offsetThresholdTAThe triggering condition is ignored for TARs triggered due to satellite handover. If the WTRU fails to report future timing advances before satellite handover, the WTRU transmits the TAR using pre-calculated timing advances during satellite handover. In one or more cases, the WTRU uses pre-calculated timing advances to transmit the UL TB.

[0145] A WTRU can be configured for RLM for same-PCI satellite handover. In the example, for Radio Link Monitoring (RLM), the WTRU can time-average cell measurements to obtain L3 cell quality. After same-PCI satellite handover, measurements and / or cell quality information associated with the previous satellite may no longer be valid. This can lead to delays in the detection of radio problems on the incoming satellite after the handover. Delayed detection can be partially addressed by rapidly acquiring numerous new measurements after the satellite handover. Acquiring new measurements for the incoming satellite may require reconfiguring measurements after the handover. For example, this process can be time-consuming, considering WTRU-gNB RTT and RLF risks. The methods and embodiments discussed herein may involve RLM enhancements to address these issues, such as delayed detection. For example, the WTRU can reset the L3 measurement window during satellite handover, apply a pre-configured measurement configuration (e.g., with denser measurement objects), and / or filter coefficients to quickly assess new channel conditions.

[0146] The WTRU can be configured for measurement configurations following a handover to the same PCI satellite. In an example, the WTRU can receive measurement configuration information to apply during a handover to the same PCI satellite. The measurement configuration may include, for example, a denser configuration of measurement objects to quickly obtain channel conditions for incoming satellites. In some examples, the measurement configuration may replace all or part of the current measurement configuration. For example, the WTRU may remove and / or reconfigure one or more aspects of the current configuration. In one or more instances, the new measurement configuration may add one or more additional measurement objects and / or identities to the current configuration. The new measurement configuration may modify (e.g., add / remove / reconfigure) other aspects of the measurement configuration, such as, but not limited to, reporting configuration, quantity configuration, measurement gaps, etc.

[0147] The WTRU can receive and store measurement configurations (one or more) prior to same-PCI satellite handover. The measurement configurations (one or more) may optionally include conditions and / or indications that can be applied during same-PCI satellite handover. In an example, the WTRU may acquire the status and / or indications, for example, via broadcast same-PCI satellite handover assistance information. In an example, the measurement configuration may include an explicit "activation time," where the measurement configuration explicitly includes the time at which the measurement configuration is applied. The WTRU can apply a new measurement configuration based on the fulfillment of conditions (e.g., the activation time / time of the same-PCI handover).

[0148] A measurement configuration may include one or more expiration conditions. These expiration conditions (one or more) may be referred to hereinafter as a “temporary measurement configuration.” Expiration conditions may be time-based. For example, a time-based expiration condition may be an explicit time. A time-based expiration condition may correspond to the end of a time period that begins when the measurement configuration is applied. Expiration conditions may be based on the number of reference signals (e.g., SSB / CSI-RS) and / or the number of objects being measured. Expiration conditions may be based on the determination of established stable channel quality. For example, expiration conditions may be based on a metric of channel quality, such as, but not limited to, measurement variance or standard deviation. Expiration conditions may be based on a measured value (e.g., RSRP / RSRQ / SINR value) exceeding or falling below a threshold. Expiration conditions may correspond to the activation of a second measurement configuration.

[0149] In one or more examples, the WTRU can apply one or more subsequent measurement configurations (e.g., a second configuration) based on the fulfillment of expiration conditions. The second configuration may have been received before the expiration conditions were met and may be stored by the WTRU. In the examples, the second configuration may include an optional indication to apply the second configuration when the first measurement configuration expires. In the examples, the measurement configuration applied during same PCI satellite handover may include an indication to store an earlier measurement configuration. For example, the indication to store an earlier measurement configuration may correspond to a configuration prior to the same PCI satellite handover. In the examples, the WTRU can revert to an earlier measurement configuration based on the fulfillment of one or more expiration conditions.

[0150] The WTRU can be configured to perform L3 filtering after a same PCI satellite handover. In an example, the WTRU can reset the L3 measurement window based on the same PCI satellite handover. The WTRU can reset the L3 measurement window to avoid detecting poor channel conditions caused, for example, by averaging measurements from the incoming satellite and measurements from the previous satellite during the same PCI satellite handover. In an example, the WTRU can discard one or more measurements associated with the previous satellite. For example, the WTRU can treat channel and / or cell quality derived values ​​(e.g., RSRP / SINR) as invalid, which include one or more measurements associated with the previous satellite. Invalid measurement results can, for example, be discarded, not used for event assessment, cell (re)selection, or mobility determination, and / or not included in measurement reports.

[0151] The WTRU can receive new or revised sets of L3 filter coefficients. For example, the WTRU can receive new or revised sets of L3 filter coefficients for application during handover to the same PCI satellite. In some cases, filter coefficients can be provided and stored together with one or more measurement configurations discussed herein. In other cases, filter coefficients can be received independently. Similar to temporary measurement configurations, the L3 filter coefficient set can be associated with one or more of the following: activation conditions; expiration conditions; an indication of a previous L3 filter coefficient set to be used upon expiration; and a second L3 filter coefficient set to be applied after the expiration of the temporary L3 filter coefficients.

[0152] The WTRU can be configured to report measurements before and / or after a handover to a same PCI satellite. To avoid reporting measurements that will soon become invalid, or to avoid triggering measurement reports before acquiring channel quality for a new cell, the WTRU can suspend measurement reporting during or before a handover to a same PCI satellite. In some cases, the WTRU can determine whether to suspend measurement reporting before a satellite handover based on explicit configuration from the network. In other cases, the WTRU can determine whether to suspend measurement reporting before a satellite handover based on explicit configuration broadcasts in system information (e.g., in same PCI satellite handover auxiliary information). Within the suspension configuration and / or indication, the WTRU can receive one or more of the following: conditions (one or more) for initiating a suspension of measurement reporting; conditions (one or more) for resuming measurement reporting; aspects of the measurement reporting to which the suspension applies (e.g., a subset of events, report type, etc.); and exceptions to the measurement reporting suspension.

[0153] The WTRU determines when to begin pausing measurement reporting based on time. For example, the WTRU may pause measurement reporting during a handover to the same PCI satellite. In some cases, the start time may occur at an offset from the handover to the same PCI satellite (e.g., 10 seconds before the handover) or at an explicit time (e.g., 10:30:02 UTC). In one or more cases, the network may optionally provide a period / duration in which measurement reporting is paused and can be maintained by the WTRU (e.g., via a disable timer).

[0154] In the examples, a pause can be applied to one or more aspects of a measurement report. For example, a pause can be applied to event-triggered measurement reports, periodic measurement reports, or both. In the examples, a pause can be applied to a subset of measurement events (e.g., pausing a measurement report triggered by A3). In the examples, a pause can be applied to measurement reports triggered by measurements performed on one or more cells or measurement objects / IDs. In some cases, such as based on the fulfillment of more than one event-based measurement trigger; based on the fulfillment of a specific event-based trigger; and / or to support recovery procedures such as radio link failures.

[0155] The WTRU can resume measurement reporting based on one or more of the following examples: WTRU can resume measurement reporting, for example, based on the expiration of a temporary measurement configuration. WTRU can resume measurement reporting, for example, based on the reconfiguration of a measurement configuration. WTRU can resume measurement reporting, for example, based on the activation of a second measurement configuration. WTRU can resume measurement reporting, for example, based on the fulfillment of measurement-based conditions (e.g., RSRP / SINR exceeding or falling below a certain threshold). WTRU can resume measurement reporting, for example, after a certain duration. WTRU can resume measurement reporting, for example, based on the arrival of an absolute time.

[0156] The WTRU can be configured with an association between measurement reports and ephemeris information. The WTRU can be configured with one or more ephemeris information for one or more satellites used for switching to the same PCI satellite. When the associated satellite position changes within a certain threshold, the WTRU can perform L3 measurement filtering. For example, when the associated satellite position change is greater than the threshold, the WTRU can reset the L3 filter and begin L3 filtering for measurements. In the example, satellite position changes can be determined based on ephemeris identifiers associated with the measurement. For example, the WTRU can be provided with one or more ephemeris, and each ephemeris can be associated with an identifier. The identifier can indicate which ephemeris ID is active, and / or from which start time (e.g., the start time associated with entering the satellite) which ephemeris ID will be active. In one or more cases, satellite position changes can be determined based on the AoD of the beam at the satellite. For example, when the AoD change of the beam (e.g., the serving beam) is greater than a threshold, an L3 filter reset for measurements can be triggered. In one or more cases, the length of the L3 filter can be determined based on one or more parameters of the ephemeris information. For example, a first L3 filter length can be used for cases where the satellite velocity is above a threshold. For satellites with speeds below a threshold, a second L3 filter length can be used, where the first L3 filter length can be shorter than the second L3 filter length.

[0157] In one or more examples, the WTRU can reset the measurement window during satellite handover to avoid averaging of channel conditions for the new satellite. 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 acquire measurements and resynchronize with the new satellite. The WTRU can temporarily suspend L3-event-based reporting before satellite handover (if channel conditions are about to change, and resources are not needed to report cell unavailability) and / or after satellite handover (to allow time for proper measurement of the new channel conditions) to avoid unnecessary reporting. For example, in the case of a changing channel condition, the WTRU can temporarily suspend L3-event-based reporting before satellite handover without using resources to report cell unavailability. Similarly, the WTRU can temporarily suspend L3-event-based reporting after satellite handover to allow time for proper measurement of the new channel conditions, thus avoiding unnecessary reporting.

[0158] Figure 5 This is a flowchart illustrating an exemplary radio link monitoring process 500 during a 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 auxiliary information about the incoming satellite. For example, the WTRU can receive (e.g., via broadcast) the time when the same PCI satellite handover will occur. At 504, the WTRU can receive configuration information for RLM for the incoming satellite. The WTRU can receive measurement configurations applied during the same PCI satellite handover. Measurement configurations can include, for example, but not limited to, one or more of the following: a temporary measurement configuration; expiration conditions for the temporary measurement configuration (e.g., the number of RSs measured, duration, etc.); a second measurement configuration (e.g., applied after the temporary measurement configuration); L3 filter coefficients applied during the satellite handover; and a configuration for suspending measurement reporting, including one or more of the following: start time and duration.

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

[0160] At 514, the WTRU can determine that the conditions for resuming the measurement report have been met, and at 518, the measurement report is resumed. At 516, the WTRU can determine whether the expiration condition has been provided. If the expiration condition for the temporary measurement configuration has not been provided, at 520, the WTRU can continue performing measurements according to the temporary measurement configuration. At 522, the WTRU can determine whether the expiration condition for the temporary measurement configuration has been met. If the expiration condition for the temporary measurement configuration is 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 the example, at 524, the WTRU can receive a second measurement configuration. If the expiration condition for the temporary measurement configuration is met and the WTRU has received the second measurement configuration, at 526, the WTRU can apply the second measurement configuration. If the expiration condition for the temporary measurement configuration is met and the second measurement configuration has not been received, at 524, the WTRU can determine to revert to (e.g., the previous measurement configuration used before satellite handover). For example, at 528, the WTRU can apply the previous (e.g., the measurement configuration before satellite handover). In one or more cases, WTRU can transmit measurement reports based on a new measurement configuration.

[0161] The WTRU can be configured for transmission processing during same-PCI satellite handover. The WTRU resynchronization time for same-PCI satellite handover can vary based on the WTRU's ability to determine or pre-determine synchronization aspects (e.g., timing advance, power control, etc.). Transmission and / or reception can be paused during resynchronization. If the network is unaware of the WTRU's resynchronization time, there may be associated risks. For example, there may be additional delays and wasted transmission opportunities (e.g., if the resynchronization time is overestimated) or the risk of missed TX and / or RX opportunities (e.g., if the resynchronization time is underestimated). The methods and embodiments discussed herein may relate to supporting appropriate resynchronization gap configuration and WTRU TX / RX processing. For example, the WTRU may send provisioning capability and / or auxiliary information regarding the resynchronization time to assist in resynchronization gap configuration and transmission processing during the resynchronization time.

[0162] The WTRU can be configured with auxiliary information for resynchronization gap configuration during same PCI satellite handover. The WTRU can be configured with a "resynchronization gap" to facilitate resynchronization with the incoming satellite during same PCI satellite handover. During the resynchronization gap, the WTRU can perform one or more resynchronization actions and / or procedures related to the incoming satellite. Resynchronization actions and / or procedures may include, for example, timing advance calculation, Doppler compensation, power control, measurement / RML, and / or beam management. During resynchronization, the WTRU may suspend (or not intend to perform) DL reception and / or UL transmission. TX and / or RX suspension may include, for example, dynamically scheduled and pre-configured transmissions (e.g., configured authorization, periodic CSI / SRS reporting, etc.).

[0163] The WTRU can provide auxiliary information (e.g., via MAC CE and / or RRC signaling) to support the proper configuration of resynchronization gaps. WTRU auxiliary information for resynchronization gap configuration may include one or more of the following: the time of performing a full resynchronization; the time of 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 handover to the same PCI satellite; the estimated time of resynchronization completion (e.g., 10:32:30:00 UTC); determining whether the WTRU can continue receiving / transmitting during the resynchronization time; the earliest time the WTRU can resume transmission / reception (e.g., 10:32:40:00 UTC); measurements of neighboring cells (e.g., in the case of backoff or RLF); and / or determining whether one or more pre-configured transmissions overlap with the resynchronization gap.

[0164] The WTRU can provide auxiliary information (such as one or more of the above) for resynchronization gap configuration. For example, the WTRU can provide one or more of the above auxiliary information based on an explicit network request. In the example, the WTRU can provide the network with auxiliary information (such as one or more of the above) for resynchronization gap configuration when establishing or re-establishing a connection (e.g., during WTRU capability transfer). In the example, the WTRU can provide auxiliary information (such as one or more of the above) for resynchronization gap configuration within a WTRU Auxiliary Information (UAI) message. In the example, the WTRU can provide auxiliary information (such as one or more of the above) for resynchronization gap configuration in a WTRU Information Response message (e.g., based on a request or indication in a WTRU Information Request message sent by the network).

[0165] The WTRU can determine, based on configured conditions, to transmit auxiliary information for resynchronization gap configuration transmissions. For example, the WTRU can determine to transmit auxiliary information based on changes between the current state of one or more information fields and / or previously reported information. Such changes between the current state of one or more information fields and previously reported information can be, for example, any amount of change. In the example, the WTRU can determine to transmit auxiliary information based on a change exceeding a configured threshold. In the example, the WTRU can determine to transmit auxiliary information at a configured time (e.g., absolute time, offset, time period) prior to a switchover to the same PCI satellite. To aid reliability, when HARQ feedback / retransmission is configured (e.g., HARQ mode A), the WTRU can transmit auxiliary information about the HARQ process.

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

[0167] Configuration information (e.g., resynchronization gap configuration information) may include one or more of the following: the start time of the resynchronization gap; the end time of the resynchronization gap; the duration of the resynchronization gap; a determination of whether to suspend one, more, or all UL transmissions / DL receptions during resynchronization (e.g., the network may instruct the suspension of one or more transmission / reception types such as periodic scheduling, but still enable other similar dynamic scheduling); a determination of which resynchronization processes to perform before resynchronization (e.g., timing pre-calculation / reporting); a determination of which resynchronization aspects to perform during the resynchronization gap; and / or information and / or configuration for performing one or more resynchronization processes. Configuration information including the start time of the resynchronization gap may, for example, indicate that the resynchronization gap begins at the same PCI satellite handover or at some other time. For example, configuration information including the start time and the duration of the resynchronization gap may indicate the expected end time of the same PCI satellite handover. For example, configuration information including the start and end times of the resynchronization gap may indicate the expected duration of the same PCI satellite handover.

[0168] In some cases, the WTRU can (e.g., via the content of WTRU auxiliary information) select, request, or suggest a resynchronization gap configuration. The network can provide confirmation of the requested configuration. In some cases, the network can pre-configure, broadcast, or indicate a set of candidate resynchronization gap configurations. For example, the network can indicate a resynchronization gap configuration by transmitting and indicating an index corresponding to the configuration.

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

[0170] In one or more scenarios, to support resynchronization gap configuration, the WTRU may transmit capability and / or ancillary information (e.g., estimated resynchronization time) prior to satellite handover. Prior to same-PCI satellite handover, the WTRU may receive configuration information for the resynchronization gap. This configuration information may include, for example, indications of the start time, end time, and / or duration of the resynchronization gap. During same-PCI satellite handover, the WTRU may initiate the resynchronization gap. In an example, the WTRU may initiate the resynchronization gap at an offset from the same-PCI satellite handover (e.g., based on indications within the configuration). While the gap is in progress, the WTRU may suspend TX and / or RX. In some cases, the WTRU may suspend pre-scheduled transmissions, such as configured authorizations, periodic CSI / SRS, etc. The WTRU may signal synchronization completion via transmissions of UL signals (e.g., but not limited to, transmissions on SR, CG, PRACH, HARQ ACK, etc.).

[0171] Figure 6This is a flowchart illustrating an exemplary transmission processing and measurement gap configuration process 600 during same-PCI satellite handover. In one or more cases, the WTRU may perform one or more of the following steps to support transmission processing and measurement gap configuration during same-PCI satellite handover. At 602, the WTRU may receive ancillary information associated with the incoming satellite. For example, the WTRU may receive (e.g., via broadcast) the time when the same-PCI satellite handover will occur. Prior to the same-PCI satellite handover, at 604, the WTRU may transmit ancillary information. The ancillary information may include one or more of the following: resynchronization duration; the WTRU's ability to perform synchronization procedures (e.g., timing pre-calculation and reporting) prior to the same-PCI satellite handover; and / or determining when the WTRU can resume RX / TX after the same-PCI satellite handover. At 606, the WTRU may receive configuration information for satellite resynchronization. Configuration information for satellite resynchronization may include one or more of the following: configuration information for resynchronization gaps; conditions for declaring resynchronization failures; and / or resources for indicating successful resynchronization (e.g., UL authorization, dedicated RACH preamble, etc.).

[0172] Based on configuration and / or auxiliary information, at 608, the WTRU can wait for a handover to occur with the same PCI satellite. At 610, during satellite handover, the WTRU can initiate a resynchronization gap and suspend UL transmission and / or DL ​​reception. At 610, the WTRU can perform one or more resynchronization procedures for entering satellite service (e.g., timing advance calculation, Doppler compensation, power control, measurement). At 612, the WTRU can successfully resynchronize with the satellite. In the event of successful resynchronization, at 616, the WTRU can resume DL reception and UL transmission. If at 620, the WTRU is configured to acknowledge or indicate successful resynchronization, the WTRU can (e.g., using available resources) transmit a successful resynchronization indication. At 612, the WTRU may fail to resynchronize with the satellite. At 614, the WTRU can time out and determine that an unsuccessful resynchronization has occurred. If no timeout is reached, the WTRU can continue performing the resynchronization gap procedure at 610 based on this configuration. At 614, WTRU can determine that there has been an unsuccessful resynchronization, and if a timeout has been reached, WTRU can declare an RLF at 618 and perform associated recovery actions.

[0173] In one or more scenarios, the WTRU can be configured to perform power control during handover to the same PCI satellite. Due to the significant positional differences between the preceding and incoming satellites, the required UL TX power may vary considerably after the handover. If the WTRU relies on conventional closed-loop power control (i.e., the WTRU waits until a power control command is received after the handover) to adjust the UL transmission power, the WTRU may risk failed transmissions if the initial transmission power is too low or there is interference. Conversely, if the initial transmission power is too high, the WTRU may risk excessive power consumption. The embodiments described herein relate to supporting power control during handover to the same PCI satellite. Furthermore, the embodiments provide a process for the WTRU to adjust the power for the initial UL transmission to the new satellite based on the distance difference between the WTRU and the old and new satellites.

[0174] The WTRU can be configured to perform autonomous TX power adjustment during same-PCI satellite handover. The WTRU can also adjust the power for the incoming satellite after same-PCI satellite handover. For example, the WTRU can adjust the power for the incoming satellite after same-PCI satellite handover to avoid using too much or too little UL power for initial transmission. The WTRU's ability to autonomously adjust transmission power can be enabled / disabled by the network. For example, the network can configure or instruct the WTRU to enable / disable its ability to autonomously adjust transmission power via RRC, which configures or instructs broadcast signaling in, for example, but not limited to, SIB, MAC CE, and / or DCI. The network can provide additional information / configurations (one or more) for calculating the initial UL TX power for the incoming satellite. Additional information / configuration (one or more) may include one or more of the following: the maximum incremental value of the original TX power that the WTRU can autonomously adjust; the maximum and / or minimum absolute TX power; a mapping between distance and power adjustment (e.g., 100km = 1dB); a mapping between distance and scaling factor (e.g., 100km = 1.25x); a determination of how to adjust the TX power (e.g., scaling by factor, increasing / subtracting power); a determination of whether to scale the total transmission power or one or more components of the transmission power (e.g., path loss); auxiliary information corresponding to the transmission characteristics entering the satellite (e.g., antenna gain); and free space coefficients, which are used to calculate changes in path loss.

[0175] In the example, the WTRU can autonomously adjust its transmission power. For instance, the WTRU can autonomously adjust its transmission power based on the satisfaction of one or more conditions. For example, the WTRU can calculate the line-of-sight probability (LOS) for the preceding and approaching satellites. If the LOS probability (e.g., LOSPI) for the preceding, approaching, or both satellites is below a configured threshold (e.g., 95%), the WTRU can non-autonomously adjust its transmission power. In some cases, the network can provide a threshold for LOS assessment of the approaching and preceding satellites. In some cases, the network can provide a threshold for each satellite.

[0176] The WTRU can assess and / or determine the path loss of an incoming satellite during a same PCI satellite handover. In the example, to support autonomous power adjustment by the WTRU, the WTRU can use ancillary information corresponding to the incoming satellite to determine the satellite's position during the same PCI satellite handover. Ancillary information can be, for example, the explicit position of the satellite during the same PCI satellite handover. In the example, the WTRU can use the ephemeris data of the incoming satellite to predict the satellite's position during the same PCI satellite handover. The WTRU can acquire its position (e.g., via GNSS) and calculate the distance between the WTRU and the incoming satellite during the same PCI satellite handover. The WTRU can use a similar set of procedures (e.g., during the same PCI satellite handover) to determine the position of the preceding satellite.

[0177] In cases where the WTRU is configured with line-of-sight conditions, the WTRU can calculate the line-of-sight probability (LOSPI) for the preceding satellite and / or the approaching satellite. Whether the WTRU calculates the LOSPI for one or both satellites may depend on whether the conditions require LOSPI evaluation for one or both satellites. The WTRU can calculate the LOSPI, for example, using auxiliary 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 signals from the approaching satellite, for example, via measurements of one or more neighboring cells originating from the approaching satellite.

[0178] In some examples, the LOSPI can be evaluated by the network. In this case, the WTRU can provide its location (e.g., current location, or estimated location during a handover to the same PCI satellite). The network can provide the LOSPI associated with one or two satellites (e.g., during a handover to the same PCI satellite) for use in condition assessment. 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.

[0179] In some examples, the WTRU can be configured to perform autonomous UL TX power adjustment during same-PCI satellite handover. During same-PCI satellite handover (or at some point between same-PCI satellite handover and the initial transmission for the incoming satellite), the WTRU can determine that autonomous transmission power adjustment is enabled and configured. If any necessary 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 WTRU autonomous power adjustment is disabled / deactivated, or if 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 for the incoming satellite.

[0180] WTRU autonomous power adjustment may be based on one or more of the following: the distance (one or more) between the WTRU and the incoming and / or preceding satellites; the incremental difference between the WTRU-previous satellite and the WTRU-incoming satellite; a determination of how the WTRU adjusts its power (e.g., whether the WTRU increases / decreases power and / or applies a scaling factor); a mapping or relationship between the distance and the determination of how the power is adjusted; the maximum absolute (or incremental) 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 used by the WTRU.

[0181] In one or more cases, the WTRU can calculate the incremental distance between the WTRU and the incoming satellite and preceding satellites. By applying a mapping from the incremental distance to incremental dB provided by the network, the WTRU can determine the amount of power adjustment (e.g., in dB). The WTRU can adjust the total transmission power based on its configuration or can adjust one or more components of the power calculation (e.g., path loss values). For cases where the incremental power adjustment exceeds the maximum / minimum allowable power adjustment, the WTRU can select boundary values. For cases where the adjustment value exceeds the WTRU's total maximum allowable transmission power, the WTRU can select the maximum allowable transmission power. The WTRU can apply the scaled power to the initial transmission to the incoming satellite after a handover to the same PCI satellite. In one or more cases, the WTRU can use the incremental distance and apply a free-space propagation loss factor to determine the variation in path loss between the incoming and preceding satellites. The WTRU can adjust the transmission power accordingly to compensate for the adjusted path loss.

[0182] In one or more cases, the WTRU may indicate the characteristics of autonomous power adjustment based on an indication or configuration. For example, the WTRU may (e.g., within a first transmission) (e.g., via MAC CE or RRC signaling) indicate the amount of adjustment that the WTRU has made to the UL TX power and / or UL TX power level. In some cases, the configuration / request may include resources for transmitting the indication (e.g., dynamic UL authorization). In other cases, the configuration / request may instruct the WTRU to include the indication in the initial transmission to the satellite.

[0183] In one or more cases, the WTRU can adjust the UL transmission power used for the initial transmission to a new satellite based on the incremental distance to the previous satellite. The UL transmission power can also be controlled by network configuration. For example, network configuration can enable / disable UL transmission power. In another example, network configuration can provide the maximum permissible incremental scaling for UL transmission. In one or more cases, the UL transmission power may be affected by conditions such as, but not limited to, the line-of-sight probability (LOSPI) for both the previous and current satellites exceeding a configured threshold.

[0184] Figure 7 This is a flowchart illustrating 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, for example, auxiliary information for the preceding and incoming satellites via broadcast. The auxiliary information may include one or more of the following: ephemeris data of the currently serving satellite; the time of the same-PCI satellite handover; and / or the location of the incoming satellite during the same-PCI satellite handover. At 704, the WTRU may receive configuration information for calculating the UL TX power for the incoming satellite. This configuration may include one or more of the following: enable / disable indication; the maximum incremental value of the original TX power that can be autonomously adjusted by the WTRU; a minimum line-of-sight probability threshold for the preceding and incoming satellites; and / or a determination of whether (e.g., within a first transmission) indicates the amount of adjustment the WTRU has made to the UL TX power and / or UL TX power level. The WTRU may acquire updated WTRU information, for example, via GNSS.

[0185] At 706, the WTRU can calculate one or more of the following: the satellite distance from the WTRU to each satellite during same PCI satellite handover (e.g., using satellite-aided information); and / or the line-of-sight probability for each satellite. The WTRU can obtain updated WTRU information (e.g., via GNSS). At 708, the WTRU can identify the start of same 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 for the incoming satellite. At 714, if WTRU autonomous UL TX power adjustment is enabled and the line-of-sight conditions for 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 use the adjusted UL TX power to transmit the initial UL transmission. If configured by NW, the WTRU can include incremental adjustments and / or the current UL TX power in the initial transmission. During same PCI satellite handover, if WTRU autonomous UL TX power adjustment is not enabled and / or line-of-sight conditions for the preceding and incoming satellites are met, the WTRU transmits the initial UL transmission at the UL TX power used for transmission to the preceding satellite. At 716, the WTRU can be configured to indicate the determined power adjustment. If the WTRU is not configured to indicate the adjustment, at 718, the adjusted power can be used to perform subsequent UL transmissions. If the WTRU is configured to indicate the adjustment, at 720, the adjusted power can be used to perform subsequent UL transmissions, and the WTRU can (e.g., during transmission) indicate the power adjustment.

[0186] The WTRU can be configured to perform beam management during the same PCI satellite handover. During the same PCI satellite handover, the serving satellite and the incoming satellite may be in very different locations. Therefore, the WTRU may need to redirect its UL TX beam after the satellite handover. In one or more cases, conventional methods are used to redirect the space filter until after the satellite handover event, which may occur after the handover. However, redirecting the space filter after the satellite handover event can increase resynchronization time and thus increase service interruption. The embodiments described herein relate to supporting appropriate measurement gap configurations and WTRU TX / RX processing.

[0187] The WTRU can measure reference signals from incoming satellites (e.g., some SSB / CSI-RS from neighboring cells) to understand how to redirect space filters when a new satellite takes over coverage. The WTRU can receive reference signals in a first time period (i.e., before handover) and a second reference signal in a second time period (i.e., after handover) as indicators / configurations of QCL measurements between linked cells.

[0188] In one or more cases, the WTRU can be configured with indications and / or configurations of QCL relationships before / after the same PCI satellite handover. The WTRU can provide QCL relationships between one or more reference signals originating from the incoming satellite and reference signals associated with the serving cell. The relationships between the one or more reference signals originating from the incoming satellite and the reference signals associated with the serving cell can be time-dependent, where the WTRU assumes (e.g., from neighboring cells originating from the incoming satellite) that the relationships between the reference signals(s) are valid after the same PCI satellite handover (e.g., the current serving cell is served by the same satellite as the neighboring cells indicated in the mapping).

[0189] In the example, the WTRU can receive a first reference signal from a first time period (e.g., a reference signal from a neighboring cell originating from an incoming satellite before a same PCI satellite handover) and a second reference signal from a second time period (e.g., a reference signal in the currently serving cell after a same PCI satellite handover) indicating and / or configuring QCL. The WTRU can link measurements performed during the first time period to support resynchronization (e.g., spatial filter determination, path loss estimation, etc.) after a same PCI satellite handover. The configuration of the first or second reference signal may include, for example, an identifier of an SSB including at least a Physical Cell Identifier (PCI) and an SSB index, and / or an identifier of a CSI-RS resource. If the second reference signal is an SSB, the WTRU can determine that the corresponding PCI is the PCI corresponding to the serving cell.

[0190] In the example, the WTRU can be configured to perform beam management during same-PCI satellite handover. Prior to same-PCI satellite handover, the WTRU can perform measurements on reference signals originating from the incoming satellite indicated in the mapping. The WTRU can use these measurements to determine transmission aspects applied to the serving cell after same-PCI satellite handover, such as spatial filtering, L3 measurements, and DL path loss. During same-PCI satellite handover, the WTRU can link the measurements from these reference signals to the current serving cell. The WTRU can then apply these transmission aspects to subsequent UL transmissions for the incoming satellite.

[0191] In one example, the WTRU can be configured to filter samples before and after a PCI handover for L3 reporting. In another example, the WTRU can utilize the latest Layer 3 filtered measurements from a first reference signal during a first time period (e.g., before the same PCI satellite handover time) to combine these measurements with first measurements from a second reference signal during a second time period (e.g., after the same PCI satellite handover time), resulting in updated filtered measurements suitable for the second reference signal. The WTRU can then use these updated filtered measurements for further Layer 3 filtering with subsequent measurements, measurement reporting, and RSRP determination for path loss estimation and uplink power.

[0192] The WTRU can be configured to determine the space RX beam based on the serving satellite's position. In one or more cases, for a given TCI state (e.g., a beam reference signal used to indicate the Rx beam at the WTRU), the WTRU can use, determine, or select the Rx beam based on the satellite's position. For example, when the serving satellite is in a first position, the WTRU can use a first RX beam; when the serving satellite is in a second position, the WTRU can use a second RX beam, and so on. The WTRU can estimate the satellite position based on ephemeris information (e.g., first-type ephemeris information and / or second-type ephemeris information). In one or more cases, when the RX beam changes, the WTRU can reset the measured L3 filter. In one or more cases, when the Rx beam changes, the WTRU can report the Rx beam information to the gNB.

[0193] The WTRU can redirect space filters (one or more) by using reference signals (e.g., SSB / CSI-RS) from neighboring cells originating from the satellite that will eventually take over the PCI. To support this mapping, the WTRU can receive a reference signal in a first time period (i.e., before satellite handover) and a second reference signal in a second time period (i.e., after satellite handover) as an indication / configuration of the QCL. In this way, whatever is measured from one satellite can be linked to the second incoming satellite.

[0194] Figure 8This is a flowchart illustrating an example of beam management during a same PCI satellite handover, process 800. In one or more cases, the WTRU may perform one or more of the following steps to support beam management during a same PCI satellite handover. At 802, the WTRU may (e.g., via broadcast) receive auxiliary information about an incoming satellite. The auxiliary information may include, for example, a time indication of the same PCI satellite handover, the location of the incoming satellite, and / or ephemeris data of the incoming satellite. At 804, the WTRU may receive an indication / configuration that a reference signal for a first time period (e.g., before the satellite handover) and a second reference signal for a second time period (e.g., after the satellite handover) are quasi-co-located (QCL).

[0195] At point 806, the WTRU can measure the reference signal originating from the incoming satellite during the first time period. At point 808, the WTRU can calculate the beam direction and / or DL ​​path loss for the incoming satellite using the reference signal from the first time period, based on the information obtained at point 806.

[0196] At 810, during a handover of the same PCI satellite, the WTRU can perform actions associated with the satellite handover. At 812, based on the mapping configuration and measurements of the reference signal from the first time period, the WTRU can redirect its UL TX beam (e.g., by applying an updated space filter) and adjust the transmission power of the initial UL transmission (e.g., based on the DL path loss measured from the first time period). The WTRU can link measurements from the first time period to measurements in the second time period. At 814, the WTRU can perform a UL transmission using the newly applied space filter and the adjusted UL power. The WTRU can transmit the same PCI satellite handover confirmation using the determined UL Tx beam and the transmission power calculated based on the RSRP of the reference signal during the first time period (e.g., using MAC CE or a pre-configured PUCCH).

[0197] In one or more cases, the WTRU can be configured to have confirmation of resynchronization completion after a same PCI switchover. The WTRU can be configured / requested / indicated to provide an indication or confirmation that the WTRU has regained synchronization with the incoming satellite after a same PCI satellite switchover. The resynchronization indication can be an explicit indication confirming that the WTRU has regained full synchronization, or it can indicate one or more aspects of regaining synchronization. In one or more cases, the confirmation may not involve aspects of resynchronization but may indicate that the WTRU can transmit and receive data from the incoming satellite. In one or more other cases, for example, based on a successful transmission to the incoming satellite at some point after a same PCI satellite switchover, the confirmation can be implicit.

[0198] In one or more cases, the WTRU may transmit indications via, for example, but not limited to, MAC CE, RRC signaling, UCI, RACH signaling (MSA, MSG3, MSG5), and / or PUSCH transmissions. The WTRU may be provided with dedicated resources (e.g., UL authorization, dedicated RACH preamble, specific RNTI) to indicate successful resynchronization, wherein upon receiving a transmission using dedicated resources, the network may assume that resynchronization is successful. The WTRU may include additional ancillary information related to one or more resynchronization processes. This additional ancillary information may include one or more of the following: timing advance, power information, measurement results, and / or beam information (e.g., as described herein).

[0199] In one or more scenarios, after a handover to the same PCI satellite, the WTRU can send the first transmission to the incoming satellite via a HARQ process configured with reliability (e.g., a HARQ process configured with HARQ mode A). In some cases, the WTRU may expect to receive the first reception from the incoming satellite via a HARQ process configured with HARQ feedback.

[0200] In one or more of these cases, the WTRU can be configured to declare a resynchronization failure. The WTRU can declare a "resynchronization failure" if it is unable to complete resynchronization with the incoming satellite. For example, if the WTRU fails to resynchronize one or more aspects (e.g., time, frequency, power, measurement) by the end of the resynchronization gap duration (or some other expiry time), the WTRU can declare a resynchronization failure. In another example, if the WTRU has a scheduled DL receive or UL transmission for the incoming satellite (e.g., after the resynchronization gap), and the WTRU is unable to perform the DL receive or UL transmission because resynchronization has not yet been completed, the WTRU can declare a resynchronization failure.

[0201] The WTRU can declare a resynchronization failure before a switchover to an inbound PCI satellite. For example, if the WTRU cannot receive the information required to perform resynchronization with the incoming satellite, it can declare a resynchronization failure before the switchover. In another example, if the connection to the previous satellite is still in place, the WTRU can report a resynchronization failure before the switchover; this failure may include one or more procedures that the WTRU cannot complete, and / or information that the WTRU cannot obtain.

[0202] In one or more of the following situations, if resynchronization of one or more aspects fails, the WTRU may declare a partial resynchronization failure. Even in the case of partial resynchronization failure, the WTRU can still restore RX / TX for the incoming satellite, however, with suboptimal configuration (e.g., incorrect power). The WTRU may indicate that one or more aspects cannot be completed, or request necessary information to resolve the issue.

[0203] Once a resynchronization failure (or partial resynchronization failure) is declared, the WTRU may perform one or more recovery actions. These actions may include, but are not limited to: beam failure recovery (BFR); radio link failure (RLF); timing advance compensation; conditional handover; cell reselection; random access; application of alternative measurement configurations; recovery of measurement reports; and / or transition to RRCINACTIVE / IDLE.

[0204] Although the features and elements have been described above in specific combinations, those skilled in the art will understand that each feature or element can be used alone or in any combination with other features and elements. Furthermore, the methods described herein can be implemented in a computer program, software, or firmware incorporated into 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, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROMs and digital multifunction discs (DVDs). The processor associated with the software can be used to implement a radio frequency transceiver used in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information indicating the time of handover from a first satellite to a second satellite using the same Physical Cell Identifier (PCI) satellite, wherein the configuration information includes an indication of the start time and an indication of the end time of the handover from the first satellite to the second satellite using the same PCI satellite; as well as Based on the configuration information indicating the time of the same PCI satellite handover, the same PCI satellite handover to the second satellite is performed.

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

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

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

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 handover.

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

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

8. The WTRU of claim 1, wherein the processor is further configured to: Transmit auxiliary information corresponding to the resynchronization time for assisting measurement gap configuration, wherein the auxiliary information includes the resynchronization duration, an indication that the WTRU can perform the synchronization process before the same PCI satellite handover, and an indication of the time when the WTRU can resume communication with the second satellite after the same PCI satellite handover.

9. The WTRU of claim 1, wherein the processor is further configured to: Receive one or more of the configurations for satellite resynchronization with the second satellite, said configurations for satellite resynchronization including resynchronization gap configurations, conditions for declaring resynchronization failures, or resources for indicating successful resynchronization with the second satellite.

10. The WTRU of claim 9, wherein the processor is further configured to transmit a resynchronization success indication in response to successful resynchronization with the second satellite.

11. A method implemented in a wireless transmit / receive unit (WTRU) for performing transmission processing during handover of satellites with the same physical cell identifier (PCI), the method comprising: Receive configuration information indicating the time of handover from a first satellite to a second satellite using the same Physical Cell Identifier (PCI) satellite, wherein the configuration information includes an indication of the start time and an indication of the end time of the handover from the first satellite to the second satellite using the same PCI satellite; as well as Based on the configuration information indicating the time of the same PCI satellite handover, the same PCI satellite handover to the second satellite is performed.

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

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

14. The method of claim 11, further comprising, in response to the same PCI satellite handover: suspending uplink transmission with the first satellite.

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

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

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

18. The method of claim 11, further comprising: Transmit auxiliary information corresponding to the resynchronization time for assisting measurement gap configuration, wherein the auxiliary information includes the resynchronization duration, an indication that the WTRU can perform the synchronization process before the same PCI satellite handover, and an indication of the time when the WTRU can resume communication with the second satellite after the same PCI satellite handover.

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

20. The method of claim 19, further comprising, in response to successful resynchronization with the second satellite: transmitting a resynchronization success indication.

21. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive configuration information via broadcast signaling indicating a handover of a same physical cell identifier (PCI) satellite from a first satellite to a second satellite, wherein the configuration information includes an indication of the start time and an indication of the end time of the same PCI satellite handover from the first satellite to the second satellite; Based on the configuration information, resynchronization is initiated for the same PCI satellite switching; In response to the switching of the same PCI satellite, uplink transmission with the first satellite is suspended; as well as Based on the configuration information indicating the same PCI satellite handover, the same PCI satellite handover to the second satellite is performed.

22. The WTRU of claim 21, wherein the processor is configured to: The same PCI satellite handover is performed during the time period associated with the resynchronization.

23. The WTRU of claim 21, wherein the processor is configured to: The resynchronization is initiated based on the indication of the start time and the indication of the end time of the same PCI satellite handover.

24. The WTRU of claim 21, wherein the processor is configured to: In response to the same PCI satellite switch, one or more resynchronization procedures are performed.

25. The WTRU of claim 24, wherein the one or more resynchronization processes include timing advance calculation, Doppler compensation, power control process, or measurement process.

26. The WTRU of claim 21, wherein the processor is configured to: Transmit auxiliary information, including the resynchronization duration, an indication that the WTRU can perform the synchronization process before the same PCI satellite handover, and an indication of the time when the WTRU can resume communication with the second satellite after the same PCI satellite handover.

27. The WTRU of claim 21, wherein the processor is configured to: Receive configuration for the resynchronization, the configuration for the resynchronization including conditions declaring resynchronization failure or resources for indicating successful resynchronization with the second satellite.

28. The WTRU of claim 21, wherein the processor is configured to: In response to the successful resynchronization with the second satellite, a resynchronization success indication is transmitted.

29. A method performed by a wireless transmit / receive unit (WTRU), the method comprising: Based on the configuration information, resynchronization is initiated when switching to the same PCI satellite. In response to the switching of the same PCI satellite, uplink transmission with the first satellite is suspended; as well as Based on the configuration information indicating the same PCI satellite handover, the same PCI satellite handover to the second satellite is performed.

30. The method of claim 29, wherein the same PCI satellite handover is performed during the time period associated with the resynchronization.

31. The method of claim 29, wherein the resynchronization is initiated based on an indication of the start time and an indication of the end time of the same PCI satellite handover.

32. The method of claim 29, comprising: In response to the same PCI satellite switch, one or more resynchronization procedures are performed.

33. The method of claim 32, wherein the one or more resynchronization processes include timing advance calculation, Doppler compensation, power control process, or measurement process.

34. The method of claim 29, further comprising: Transmit auxiliary information, including the resynchronization duration, an indication that the WTRU can perform the synchronization process before the same PCI satellite handover, and an indication of the time when the WTRU can resume communication with the second satellite after the same PCI satellite handover.

35. The method of claim 29, comprising: Receive configuration for resynchronization, the configuration for resynchronization including conditions declaring resynchronization failure or resources indicating successful resynchronization with the second satellite.

36. The method of claim 29, comprising: In response to the successful resynchronization with the second satellite, a resynchronization success indication is transmitted.

Images