Method for mobility triggered location verification

Abstract

A method for mobility triggered location verification is provided herein. A method may include receiving assistance information including at least satellite ephemeris information, and detecting movement from a reference point, where the movement exceeds a distance threshold. The method may include determining a location verification occasion based on the received satellite ephemeris information. The method may include transmitting location verification information to the network at the determined location verification occasion under the condition that the determined location verification occasion is within a time threshold. The auxiliary information may include an indication of the distance threshold. The auxiliary information may include an indication of the time threshold. The method may also include detecting a mobility event. The method may also include performing an initial access to establish a connection to the network under a condition that the determined authentication occasion occurs after a pre-configured time from the detected mobility event.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to U.S. provisional application 63 / 445,628, filed February 14, 2023, the contents of which are incorporated by reference herein. BACKGROUND

[0003] Non-Terrestrial Networks (NTNs) can facilitate deployment of wireless networks in areas where ground-based antennas are impractical, e.g., due to geography or cost. Coupled with terrestrial networks, NTNs can enable truly ubiquitous coverage of 5G networks. Initial 3GPP Rel-17 NTN deployments support basic voice and text anywhere in the world; however, further releases associated with the proliferation of next-generation low-earth orbit satellites are expected to enable enhanced services such as web browsing.

[0004] Basic NTNs can include air- or space-borne platforms that transmit signals from ground base stations to WTRUs via a gateway (GW) and vice versa. For example, current Rel-17 NR NTNs can support power class 3 WTRUs with omni-directional antenna(s) and linear polarization, or very small aperture terminal (VSAT) terminals with directional antenna(s) and circular polarization. Support for LTE-based Narrowband IoT (NB-IoT) and eMTC-type devices is also standardized in Rel-17, with all Rel-17 NTN WTRUs assumed to have global navigation satellite system (GNSS) capability regardless of device type. SUMMARY

[0005] Methods for mobility-triggered location verification are provided herein. One method can include receiving assistance information comprising at least satellite ephemeris information, and detecting a movement from a reference point, where the movement exceeds a distance threshold. The method can include determining a location verification occasion based on the received satellite ephemeris information. The method can include transmitting location verification information to a network at the determined location verification occasion on a condition that the determined verification occasion is within a time threshold. The assistance information can include an indication of the distance threshold. The assistance information can include an indication of the time threshold. The method can further include detecting a mobility event. The method can further include performing an initial access to establish a connection to the network on a condition that the determined verification occasion occurs after a preconfigured time from the detected mobility event. BRIEF DESCRIPTION OF DRAWINGS

[0006] The application can be understood in more detail with reference to the following description and drawings wherein:

[0007] Figure 1Ais a system diagram illustrating an example communications system in which one or more disclosed embodiments can be implemented;

[0008] Figure 1B is a system diagram illustrating an example satellite positioning system (SPS) in accordance with an embodiment that can be used within the Figure 1A communications system shown in FIG. 1;

[0009] Figure 1C is a system diagram illustrating an example satellite positioning system (SPS) in accordance with an embodiment that can be used within the Figure 1A communications system shown in FIG. 1;

[0010] Figure 1D is a system diagram illustrating an example satellite positioning system (SPS) in accordance with an embodiment that can be used within the Figure 1A communications system shown in FIG. 1;

[0011] Figure 2 is a diagram depicting different parties and interfaces in a non-terrestrial network;

[0012] Figure 3 is a diagram illustrating an example of discontinuous coverage;

[0013] Figure 4 is a diagram illustrating an example of preparation time of a WTRU in relation to actual validation occasions;

[0014] Figure 5 is a diagram illustrating an example procedure for RTT-based positioning;

[0015] Figure 6 is a diagram illustrating a relationship between satellite positions, PRS reception, and SRS transmission from a WTRU;

[0016] Figure 7 is a diagram illustrating configuration of a WTRU with periodic validation occasions from a network;

[0017] Figure 8 is a diagram illustrating a visible period of a satellite;

[0018] Figure 9 is a diagram illustrating determination of a new validation occasion;

[0019] Figure 10 is a diagram illustrating rejection of a new validation occasion;

[0020] Figure 11 is a diagram illustrating a position validation determination performed by a WTRU;

[0021] Figure 12FIG. 1 is a diagram illustrating an example of a WTRU determining periodicity for location verification;

[0022] Figure 13 FIG. 3 is a diagram illustrating an example of a relationship between a minimum periodicity required for verification and a distance from a center of an NTN cell;

[0023] Figure 14 FIG. 4 is a diagram illustrating an example of a set of verification occasions;

[0024] Figure 15 FIG. 5 is a flow diagram illustrating an example procedure for a mobility triggered location verification;

[0025] Figure 16 FIG. 6 is a flow diagram illustrating an example procedure for a network initiated verification with a penalty for skipping occasions; and

[0026] Figure 17 FIG. 7 is a flow diagram of an example procedure for a WTRU initiated location verification. DETAILED DESCRIPTION

[0027] Figure 1A FIG. 1 is a diagram illustrating an example communications system 100 in which one or more disclosed embodiments can be implemented. The communications system 100 can be a multiple access system that provides content, such as voice, data, video, messaging, broadcast, etc., to multiple wireless users. The communications system 100 can enable multiple wireless users to access such content through the sharing of system resources, including wireless bandwidth. For example, the communications systems 100 can 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 discrete Fourier transform spread orthogonal frequency de- vices (ZT-UW DFT-S-OFDM), unique word OFDM (UW-OFDM), resource block-filtered OFDM, filter bank multicarrier (FBMC), and the like.

[0028] As Figure 1AAs shown, the communication system 100 can include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, a radio access network (RAN) 104 / 113, a core network (CN) 106, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, though it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, 102d can be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which can be referred to as a "station" (STA)) can be configured to transmit and / or receive wireless signals, and can include a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smartphone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (loT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot or other wireless devices operating in an industrial and / or an automated processing chain environments), a consumer electronics, a device operating on a commercial and / or industrial wireless network, and the like. Any of the wireless transmit / receive units 102a, 102b, 102c, and 102d can be interchangeably referred to as a UE.

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

[0030] The base stations 114a can be part of the RAN 104, which can also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), relay nodes, etc. The base stations 114a and / or the base stations 114b can be configured to communicate with the WTRUs 102a, 102b, 102c, and / or 102d on one or more carrier frequencies. The frequencies at which the base stations 114a and / or 114b communicate with the WTRUs 102a, 102b, 102c, and / or 102d can be referred to as a cell (not shown). The carrier frequency can be any suitable carrier frequency

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

[0032] More specifically, as noted above, the communications 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, and the like. For example, the base station 114a in the RAN 104 and the WTRUs 102a, 102b, 102c can implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which can establish the air interface 116 using wideband CDMA (WCDMA). 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 Uplink (UL) Packet Access (HSUPA).

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

[0034] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement a radio technology such as NR Radio Access, which can establish the air interface 116 using NR.

[0035] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c can implement multiple radio access technologies. For example, the base station 114a and WTRUs 102a, 102b, 102c can implement LTE wireless access and NR wireless access together, for instance using dual connectivity (DC) principles. Thus, the air interface utilized by WTRUs 102a, 102b, 102c can be characterized by multiple types of radio access technologies and / or transmissions sent to / from multiple types of base stations (e.g., an eNB and a gNB).

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

[0037] Figure 1AThe base station 114b in the FIG. 1B can be a wireless router, Home Node B, Home eNode B, or access point, for example, and can utilize any suitable RAT for facilitating wireless connectivity access. The base station 114b and the WTRUs 102c, 102d in the FIG. 1B can implement a radio technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114b and the WTRUs 102c, 102d can implement a radio technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In yet another embodiment, the base station 114b and the WTRUs 102c, 102d can utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish a picocell or femtocell. As shown in the FIG. 1B, the base station 114b can have a direct connection to the Internet 110. Thus, the base station 114b can not be required to access the Internet 110 via the CN 106 / 115. Figure 1A

[0038] The RAN 104 can be in communication with the CN 106, which can be any type of network configured to provide voice, data, applications, and / or voice over internet protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. The data can have varying quality of service (QoS) requirements, such as differing throughput requirements, latency requirements, error tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, and the like. The CN 106 can provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions, such as user authentication. Although not shown in the FIG. 1A, a Figure 1A Although not shown in the FIG. 1A, it will be appreciated that the RAN 104 and / or the CN 106 can be in direct or indirect communication with other RANs that employ the same RAT as the RAN 104 or a different RAT. For example, in addition to being connected to the RAN 104, which can employ a NR radio technology, the CN 106 can also be in communication with another RAN (not shown) employing a GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

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

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

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

[0042] The processor 118 can be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Array (FPGAs), any other type of integrated circuit (IC), a state machine, and the like. The processor 118 can perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 can be coupled to the transceiver 120, which can be coupled to the transmit / receive element 122. While Figure 1B The processor 118 and the transceiver 120 are depicted as separate components, it is to be understood that the processor 118 and the transceiver 120 can be integrated together in an electronic package or chip.

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

[0044] Although the transmit / receive element 122 is depicted in the WTRU 102 Figure 1B In one embodiment, the WTRU 102 can include two or more transmit / receive elements 122 (e.g., multiple antennas) to facilitate MIMO technology. In this embodiment, the transmit / receive element 122 can be configured to transmit and / or receive wireless signals, respectively, using multiple antennas.

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

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

[0047] The processor 118 can receive power from the power source 134, and can be configured to distribute and / or control the power to the other components in the WTRU 102. The power source 134 can be any suitable device for powering the WTRU 102. For example, the power source 134 can 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, and the like.

[0048] The processor 118 can also be coupled to the GPS chipset 136, which can be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. In addition to, or

[0049] The processor 118 can further be coupled to other peripherals 138, which can include one or more software and / or hardware modules that provide additional features, functionality and / or wired or wireless connectivity. For example, the peripherals 138 can include an accelerometer, an e-compass, a satellite transceiver, a digital camera (for photographs or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands- free headset, a Bluetooth® The peripheral device 138 can include one or more sensors. The sensors can be one or more of the following: a gyroscope, an accelerometer, a hall effect sensor, a magnetometer, a direction sensor, a proximity sensor, a temperature sensor, a time sensor; a geopositioning sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, a humidity sensor, etc.

[0050] The WTRU 102 can include a full duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for UL (e.g., for transmission) and DL (e.g., for reception) can be concurrent and / or simultaneous. The full duplex radio can include an interference management unit to reduce and / or substantially eliminate self-interference and / or cross- interference due to concurrent transmission and reception. In one embodiment, the WTRU 102 can include a half duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes for UL (e.g., for transmission) or DL (e.g., for reception).

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

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

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

[0054] Figure 1C The CN 106 shown in FIG 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 the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

[0058] The CN 106 can facilitate communications with other networks. For example, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional landline communications devices. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers.

[0059] Although WTRUs are described in Figures 1A-1D representative embodiments as wireless terminals, it is contemplated that in certain representative embodiments such a terminal can use a wired communication interface with the communication network (e.g., on a temporary or permanent basis).

[0060] In representative embodiments, the other networks 112 can be a WLAN.

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

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

[0063] High Throughput (HT) STAs can use 40 MHz wide channels, for example, by combining the primary 20 MHz channel with an adjacent or nonadjacent 20 MHz channel to form a 40 MHz wide channel.

[0064] Very High Throughput (VHT) STAs can support 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz wide channels. 40 MHz and / or 80 MHz channels can be formed by combining contiguous 20 MHz channels. A 160 MHz channel can be formed by combining 8 contiguous 20 MHz channels, or by combining two noncontiguous 80 MHz channels, which can be referred to as an 80+80 configuration. For the 80+80 configuration, after channel encoding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be separately subjected to inverse fast Fourier transform (IFFT) processing and time domain processing. The streams can be mapped on to the two 80 MHz channels, and the data can be transmitted by a transmitting STA. At the receiver of the receiving STA, the above-described 80+80 configuration operations can be reversed, and the combined data can be sent to the medium access control (MAC).

[0065] Operation modes below 1 GHz are supported by 802.11af and 802.11ah. Channel operating bandwidths and carriers in 802.11af and 802.11ah are reduced relative to those used in 802.11η and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in TV White Space (TVWS) spectrum, while 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to representative embodiments, 802.11ah can support meter-type control / machine-type communication (MTC), such as MTC devices in a macro coverage area. MTC devices can have certain capabilities, for example, including limited capabilities such as support (e.g., only support) for certain and / or limited bandwidths. MTC devices can include a battery with a battery life above a threshold (e.g., to maintain a very long battery life).

[0066] WLAN systems that can support multiple channels and channel bandwidths (e.g., 802.11η, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as a primary channel. The primary channel can have a bandwidth equal to a 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 among all STAs operating in the BSS that supports the smallest bandwidth operating mode. In the example of 802.11ah, for a STA (e.g., a MTC-type device) that supports (e.g., only supports) a 1 MHz mode, the primary channel can be 1 MHz wide even if other STAs in the AP and BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings can depend on the status of the primary channel. If the primary channel is busy, for example, due to a STA (which only supports a 1 MHz operating mode) transmitting to the AP, then all available frequency bands can be considered busy even if most of the frequency band remains idle and available.

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

[0068] Figure 1Dis a system diagram illustrating the RAN 104 and the CN 106 according to an embodiment. As described above, the RAN 104 can employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 104 can also be in communication with the CN 106.

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

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

[0071] The gNBs 180a, 180b, 180c can be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In the standalone configuration, the WTRUs 102a, 102b, 102c can communicate with one or more of gNBs 180a, 180b, 180c without also accessing other RANs (e.g., eNode-Bs 160a, 160b, 160c). In the standalone configuration, the WTRUs 102a, 102b, 102c can utilize one or more of gNBs 180a, 180b, 180c as a mobility anchor point. In the standalone configuration, the WTRUs 102a, 102b, 102c can use

[0072] Each of the gNBs 180a, 180b, 180c can be associated with a particular cell (not shown) and can be configured to handle radio resource management decisions, handover decisions, scheduling of users in the UL and / or DL, support of network slicing, DC, interworking with E-UTRA, routing of user plane data towards user plane functions (UPFs) 184a, 184b, routing of control plane information towards access and mobility management functions (AMFs) 182a, 182b, and the like. As shown, the gNBs 180a, 180b, 180c can communicate with one another over an Xn interface. Figure 1D As shown, the gNBs 180a, 180b, 180c can be in communication with the AN 180a, 180b, 180c over an Xn interface.

[0073] Figure 1DThe CN 106, as shown in FIG. 10, can include at least one AMF 182a, 182b, at least one UPF 184a, 184b, at least one Session Management Function (SMF) 183a, 183b, and can include a Data Network (DN) 185a, 185b. While the foregoing elements are depicted as part of the CN 106, it will be appreciated that any of these elements can be owned and / or operated by an entity other than the CN operator.

[0074] The AMF 182a, 182b can be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 104 via an N2 interface and can serve as a control node. For example, the AMF 182a, 182b can be responsible for authenticating the WTRUs 102a, 102b, 102c, support for network slicing (e.g., handling of different protocol user unit (PDU) sessions with different requirements), selection of a particular SMF 183a, 183b, management of the WTRU 102a, 102b, 102c registration area, termination of non-access stratum (NAS) signaling, mobility management, and the like. The AMF 182a, 182b can utilize network slicing to customize CN support for the WTRUs 102a, 102b, 102c, based on the type of service being accessed by the WTRUs 102a, 102b, 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, services for MTC access, and the like. The AMF 182a, 182b can provide the control plane functionality to manage the WTRU 102a, 102b, 102c

[0075] The SMF 183a, 183b can be connected to AMF 182a, 182b in the CN 106 via an N11 interface. The SMF 183a, 183b can also be connected to the UPF 184a, 184b in the CN 106 via an N4 interface. The SMF 183a, 183b can select and control the UPF 184a, 184b and configure the routing of traffic through the UPF 184a, 184b. The SMF 183a, 183b can perform other functions, such as managing and allocating IP address, managing PDU sessions, controlling policy enforcement and QoS, providing DL data notifications, and the like. A PDU session type can be IP-based, non-IP based, Ethernet-based, and the like.

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

[0077] The CN 106 can facilitate communications with other networks. For example, the CN 106 can include, or can communicate with, an IP gateway (e.g., an IP multimedia subsystem (IMS) server) that serves as an interface between the CN 106 and the PSTN 108. Further, the CN 106 can provide the WTRUs 102a, 102b, 102c with access to the other networks 112, which can include other wired and / or wireless networks that are owned and / or operated by other service providers. In one embodiment, the WTRUs 102a, 102b, 102c can be connected to a local DN 185a, 185b through the UPF 184a, 184b via the N3 interface and the N6 interface between the UPF 184a, 184b and the DN 185a, 185b.

[0078] In view of Figures 1A-1D and Figures 1A-1D In view of the respective descriptions of the above, one or more or all of the functions described herein with regard to one or more of the WTRUs 102a-d, base stations 114a-b, eNode-Bs 160a-c, MME 162, SGW 164, PGW 166, NodeBs 180a-c, AMF 182a-b, UPF 184a-b, SMF 183a-b, DN 185a-b, and / or any other device described herein can be performed by one or more emulation devices (not shown). The emulation devices can be one or more devices configured to emulate one or more or all of the functions described herein. For example, the emulation devices can be used to test other devices and / or to simulate network and / or WTRU functionality.

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

[0080] The emulation device(s) can perform one or more, including all, functions while not being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used in a testing lab and / or a testing scenario in a non-deployed (e.g., testing) wired and / or wireless communication network in order to implement testing of one or more components. The emulation device(s) can be test equipment. The emulation devices can transmit and / or receive data using direct RF coupling and / or over-the-air, wireless communication via RF circuitry (which can include one or more antennas), for example.

[0081] A list of abbreviations and acronyms is provided below for ease of reference:

[0082] ACK acknowledgement

[0083] AoA angle of arrival

[0084] AoD angle of departure

[0085] ARFCN absolute radio frequency channel number

[0086] BLER block error rate

[0087] BW bandwidth

[0088] BWP bandwidth part

[0089] CAP channel access priority

[0090] CAPC channel access priority class

[0091] CCA clear channel assessment

[0092] CCE control channel element

[0093] CE control element

[0094] CG configured grant or cell group

[0095] CORESET control resource set

[0096] CP cyclic prefix

[0097] CP-OFDM (cyclic prefix dependent) conventional OFDM

[0098] CQI channel quality indicator

[0099] CRC cyclic redundancy check

[0100] CSI channel state information

[0101] CW contention window

[0102] CWS contention window size

[0103] CO channel occupancy

[0104] DAI downlink assignment index

[0105] DCI downlink control information

[0106] DFI downlink feedback information

[0107] DG dynamic grant

[0108] DL downlink

[0109] DM-RS demodulation reference signal

[0110] DRB data radio bearer

[0111] DRX discontinuous reception

[0112] ECID enhanced cell ID

[0113] eLAA enhanced license assisted access

[0114] eMMB enhanced mobile broadband

[0115] FeLAA further enhanced license assisted access

[0116] GNSS global navigation satellite system

[0117] GPS global positioning system

[0118] HARQ hybrid automatic repeat request

[0119] IM interference measurement

[0120] LAA license assisted access

[0121] LBT listen before talk

[0122] LCH logical channel

[0123] LCPL logic channel priority

[0124] LBT listen before talk

[0125] LOS line of sight

[0126] NLOS non-line of sight

[0127] LMF location management function

[0128] LPP LTE positioning protocol

[0129] LTE long term evolution (e.g., from 3GPP LTE R8 and beyond)

[0130] MAC CE MAC control element

[0131] MAC medium access control

[0132] MCS modulation and coding scheme

[0133] MIMO multiple input multiple output

[0134] NACK negative ACK

[0135] NAS non-access stratum

[0136] NGSO non-geostationary satellite system

[0137] NR new radio

[0138] NTN non-terrestrial network

[0139] OFDM orthogonal frequency division multiplexing

[0140] OTDOA observed time difference of arrival

[0141] PDCCH physical downlink control channel

[0142] PDSCH physical downlink shared channel

[0143] PDU protocol data unit

[0144] PHY physical layer

[0145] PID process ID

[0146] PO paging occasion

[0147] PRACH physical random access channel

[0148] PRS positioning reference signal

[0149] PRU positioning reference unit

[0150] PSS primary synchronization signal

[0151] PTRS phase tracking reference signal

[0152] PUCCH physical uplink control channel

[0153] PUSCH physical uplink shared channel

[0154] RA random access (or procedure)

[0155] RACH random access channel

[0156] RAR random access response

[0157] RCU radio access network central unit

[0158] RE resource element

[0159] RF radio frequency front end

[0160] RLF radio link failure

[0161] RLM radio link monitoring

[0162] RNTI radio network identifier

[0163] RNA RAN notification area

[0164] RO RACH occasion

[0165] RRC radio resource control

[0166] RRM radio resource management

[0167] RTT round trip time

[0168] RP reception point

[0169] RS reference signal

[0170] RSRP reference signal received power

[0171] RSTD reference signal time difference

[0172] RTT round trip time

[0173] RSSI received signal strength indication

[0174] RTOA relative time of arrival

[0175] SDAP service data adaptation protocol

[0176] SDU service data unit

[0177] SRB signaling radio bearer

[0178] SRS sounding reference signal

[0179] SS synchronization signal

[0180] SSS secondary synchronization signal

[0181] SWG switch gap (in self-contained subframe)

[0182] SPS semi-persistent scheduling

[0183] SUL supplementary uplink

[0184] TB transport block

[0185] TBS transport block size

[0186] TDoA time difference of arrival

[0187] TRP transmission-reception point

[0188] TP transmission point

[0189] TSC time sensitive communication

[0190] TSN time sensitive network

[0191] TTI transmission time interval

[0192] UCI uplink control information

[0193] UL uplink

[0194] URLLC ultra-reliable low-latency communication

[0195] WBWP wideband component

[0196] WLAN wireless local area network and related technologies (IEEE 802.xx domain)

[0197] Rel-17 NTN deployment scenarios are described herein. Non-terrestrial or space-borne platforms can be categorized according to orbit, with Rel-17 standardization focusing on low earth orbit (LEO) satellites with a height range of 300-1500 km and geostationary orbit (GEO) satellites with a height of 35786 km. Other platform categories can be supported, such as medium earth orbit (MEO) satellites with a height range of 7000-25000 km and high altitude platform stations (HAPS) with a height of 8-50 km. Satellite platforms can be further categorized as having a “transparent” or “regenerative” payload. A transparent satellite payload can implement frequency conversion and RF amplification in the uplink and downlink, with multiple transparent satellites possibly connected to one (or more) ground-based base station(s). A regenerative satellite payload can implement a full base station or base station DU on the satellite. A regenerative payload can perform digital processing on the signal, including demodulation, decoding, re-encoding, re-modulation, and / or filtering.

[0198] Figure 2 Interfaces in a non-terrestrial network (NTN) are depicted. The NTN can include a ground segment composed of one or more base stations 210, each having a gateway (GW) 211 or in communication therewith, which communicates with satellites 221 and 222 that are part of an NTN constellation. The GW 211 can establish and maintain a connection with the satellites 221 and 222, enabling data transfer between a terrestrial network and space-based assets. The satellites 221 and 222 provide service to one or more WTRUs 230 within their coverage areas. The NTN can include one or more WTRUs 230, which can be, for example, smartphones, tablets, IoT devices, and / or specialized equipment configured to connect to both the terrestrial 5G infrastructure and the satellites in the NTN. If configured to connect to both the terrestrial 5G infrastructure and the NTN devices, the NTN devices can have the ability to seamlessly handover between ground and satellite connections, depending on the coverage area.

[0199] As shown in Figure 2 the following wireless interfaces can be defined in the NTN: one or more feeder links (e.g., the wireless links between the GW 211 and the satellites 221 and 222); one or more service links (e.g., the radio links between the satellite 222 and the WTRUs 230); and one or more inter-satellite links (ISLs), which can include, for example, the transmission links between the satellites 221 and 222, which can be supported only by regenerative payloads and can be either a 3GPP radio interface or a proprietary optical interface.

[0200] Regenerative payload can refer to a payload designed to help reception, processing, and retransmission of signals to improve the quality and efficiency of ISL and / or service link. Various techniques can be used to transmit regenerative payload, such as amplification, error correction, frequency correction, beamforming, etc., allowing NTNs to extend coverage, enhance signal quality, and provide reliable communications.

[0201] Depending on the satellite payload configuration, different 3GPP interfaces can be used for each radio link. In the case of transparent payload, the NR-Uu wireless interface can be used for both service link and feeder link. For regenerative payload, the NR-Uu interface can be used on the service link and a satellite radio interface (SRI) can be used for the feeder link. 3GPP has not yet defined ISL for Rel-17. Detailed UP / CP protocol stacks for transparent payload configuration, which can be used consistently with 3GPP TR 38.821, are described in later paragraphs herein.

[0202] NTN satellites can support multiple cells, and each cell can provide coverage via one or more satellite beams. Satellite beams can cover a coverage area on Earth (e.g., similar to terrestrial cells), and their diameters can range from 100 to 1000 km in LEO deployments and from 200 to 3500 km in GEO deployments. For example, in GEO deployments, beam coverage areas can remain fixed relative to Earth, and for example, in LEO deployments, the area covered by a beam / cell can change over time due to satellite movement. Such beam movement can be classified as “Earth-moving,” where the beam continuously moves across the Earth, or as “Earth-fixed,” where the beam is steered to maintain coverage over a fixed location until a new cell exceeds the coverage area in discrete and coordinated changes.

[0203] Due to the height of the NTN platform and the beam diameter, the round-trip time (RTT) and the maximum differential delay can be significantly larger than the round-trip time and the maximum differential delay of terrestrial systems. In a typical transparent NTN deployment, the RTT can range from 25.77 ms (LEO @ 600 km altitude) to 541.46 ms (GEO), and the maximum differential delay can range from 3.12 ms to 10.3 ms. The RTT of regenerative payload can be approximately half of the RTT of transparent payload, as the transparent configuration includes both service and feeder links, while the RTT of regenerative payload can consider only the service link. To minimize the impact on existing NR systems (e.g., to avoid preamble ambiguity or to correctly time the reception window), the WTRU can perform timing pre-compensation before initial access.

[0204] User plane enhancements are described herein.

[0205] Time / frequency pre-compensation is one type of user plane enhancement that can be performed in Rel-17 NTN. The pre-compensation procedure can prompt or require the WTRU to obtain its location through GNSS and obtain the feeder link (or common) delay and satellite position through satellite ephemeris data. Satellite ephemeris data can be periodically broadcasted in system information and can contain information such as satellite velocity, direction, and velocity. The WTRU can then estimate the distance (and thus the delay) to the satellite and then add the feeder link delay component to obtain the full WTRU- base station RTT, which can then be used to offset timers, reception windows, or timing relationships (e.g., timing relationships related to random access, including ra-ResponseWindow, msgb-ReponseWindow, and ra-ContentResolutionTimer). Frequency compensation can be assumed to be performed by the network and / or WTRU. Examples of frequency compensation described herein can include correction, application, and / or removal of frequency offsets in carrier frequency.

[0206] Since the WTRU-specific TA (and thus the WTRU base station RTT) can be computed by the WTRU, a new procedure can be defined in Rel-17 to report the TA estimate to the network via a new MAC CE or other logically equivalent signaling. Timing advance reporting (TAR) can be triggered based on one or more of the following conditions: trigger timing advance reporting according to an indication from upper layers; if the WTRU has not previously reported a timing advance value to the current serving cell when offsetThresholdTA is configured by upper layers; if configured, the change between the current information on the timing advance and the last reported information on the timing advance is equal to or greater than offsetThresholdTA.

[0207] HARQ and DRX enhancements are described herein. A WTRU can be semi-statically configured (e.g., via RRC signaling) to apply specific HARQ behavior to a set of HARQ process IDs (or in other words, to associate certain HARQ behavior or processes with one or more HARQ process IDs). The configuration can be performed per serving cell and can be optionally configured for both UL and DL HARQ processes via one or more optional configurations. One optional configuration or parameter (referred to herein as “downlinkHARQ-feedbackDisabled”) can be configured per HARQ process ID and can indicate whether DL HARQ feedback is enabled or disabled. Another optional configuration or parameter (referred to herein as uplinkHARQ-Mode) can be configured per HARQ process ID and can indicate whether the UL HARQ process uses HARQModeA or HARQModeB. HARQModeA can be best applied to transmissions with UL HARQ retransmission enabled, while HARQModeB can be best applied to transmissions with UL HARQ retransmission disabled or blind UL retransmission.

[0208] A WTRU can adapt DRX timers based on the configured HARQ characteristics of a HARQ process. DRX can be applied for both UL and DL to adapt the DRX active time to account for additional propagation delay (e.g., if HARQ feedback is enabled) or to enable additional WTRU power saving (e.g., if HARQ feedback is disabled). Operation can be adjusted as follows.

[0209] For DL operation, if the parameter “downlinkHARQ-FeedbackDisabled” is configured for the serving cell, one or more of the following conditions can be applied at the time of DL reception. If HARQ feedback is enabled for a HARQ process, the WTRU can extend the length of the DL HARQ RTT timer by or based on the WTRU- base station RTT (i.e., the propagation delay). If HARQ feedback is disabled for a HARQ process, the WTRU can not start the drx-RetransmissionTimerDL to enable additional power saving. If the parameter downlinkHARQ-FeedBackDisabled is not configured, the WTRU can apply legacy behavior (i.e., start the drx-RetransmissionTimerDL after the expiration of the time window defined by the drx-HARQ-RTT-TimerDL).

[0210] For UL operation, one or more of the following conditions can be applied at the time of UL transmission if uplinkHARQ-Mode is configured for the serving cell. If the HARQ process is configured as HARQModeA, the WTRU can extend the length of the DL HARQ RTT timer by the WTRU- base station RTT (i.e., extend the DL HARQ RTT timer by the propagation delay). If the HARQ process is configured as HARQModeB, the WTRU can not start the drx- RetransmissionTimerDL to achieve additional power saving. If uplinkHARQ-Mode is not configured, the WTRU will apply legacy behavior (i.e., start the drx- RetransmissionTimerUL after the expiration of the drx-HARQ-RTT-TimerUL).

[0211] LCP enhancements based on HARQ behavior are described herein. A WTRU can be configured to apply LCP restrictions based on the UL HARQ mode configured for the HARQ process ID to which the UL grant is assigned. WTRU behavior can be specified via two or more optional RRC configurations. One example can be the parameter uplinkHARQ-Mode, which can configure each HARQ process ID as either HARQModeA or HARQModeB. Another example can be the parameter allowedHARQ-Mode, which can be configured per logical channel and can set the allowed HARQ mode for the HARQ processes mapped to that logical channel.

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

[0213] A description of control plane enhancements is provided herein. RRC CONNECTED enhancements that can be used in Rel-17 NTN are described in detail below. Rel-17 enhancements related to RRC CONNECTED mode can focus on adapting mobility and measurement procedures to non-terrestrial environments. Key modifications to mobility and measurement procedures can include additional execution conditions for conditional handover (such as A4 event), and time / location based conditions. Such modifications are further described in the following paragraphs. In IDLE mode, a WTRU can not have any connection to the network, and mobility (i.e., cell (re)selection) is performed by the WTRU. The WTRU can need to establish a connection with the network in order for the WTRU to transition to RRC CONNECTED mode. During RRC CONNECTED mode, the WTRU can transmit and / or receive data to / from the network, and procedures such as measurement reporting and mobility between cells are controlled by the network. During INACTIVE mode, the WTRU can remain connected to the core network (i.e., WTRU context is known and stored at the core network), however the WTRU can not be connected to the RAN network. The WTRU can retain the context (e.g., configuration) obtained by the WTRU during RRC CONNECTED mode. During INACTIVE mode, the WTRU can be in a dormant mode during which the WTRU can not monitor channels or signals transmitted from the network. During INACTIVE mode, the WTRU can wake up based on configured trigger events to receive or monitor channels or signals transmitted by the network. The WTRU can wake up based on configured trigger events to transmit signals or channels to the network during INACTIVE mode.

[0214] Some examples of location based events can be defined, for example, by condEventD1, where the event can be satisfied if the distance between the WTRU and a first reference location (e.g., a location associated with a serving cell or a location within a serving cell) is above a threshold and a second reference location (e.g., a location associated with a neighboring cell or a location within a neighboring cell) is below a threshold. Time based events can be defined, for example, by condEventT1, where the event can be satisfied if the conditional handover execution occurs between T1 and T2, where T2 = T1 + duration. Time and location based trigger conditions can need to be configured simultaneously with the measurement conditions (e.g., A4) for Rel-17 NTN.

[0215] Some methods, enhancements, or modifications to existing procedures can be applied to measurements and can include one or more of the following aspects. Some modifications can include location-based measurement reporting (based on event D1 with similar execution conditions as condEventD1). In some methods, parameters such as the propagation delay difference, feeder link delay, and serving / neighbor cell satellite ephemeris information can be used to configure multiple SSB / PBCH block measurement timing configurations (SMTC) for a given set of cells (e.g., per carrier). In some methods, measurement gaps can be configured using the same propagation delay difference as calculated for SMTC. Enhanced mobility can be of particular interest in LEO deployments, where even stationary WTRUs can expect to perform mobility procedures, for example, approximately every seven seconds (e.g., depending on deployment characteristics) due to satellite movement.

[0216] Methods for RRC_IDLE / INACTIVE state are presented herein. The methods presented in the following paragraphs can include or involve enhancements to existing procedures defined for Rel-17 NTN. Rel-17 enhancements to idle / inactive cell reselection can focus on, for example, new measurement rules. Some enhancements can be specified based on the distance of the WTRU from a cell reference point and / or based on the time a quasi- Earth cell will stop serving the current area (which can be indicated and referred to by the parameter t-Service throughout the paragraphs herein). The cell reference point, the parameter t-Service, and the distance Thresh (e.g., representing a parameter for evaluating distance conditions) can be broadcast in system information (e.g., SIB19), which is a new system information block that can carry NTN-specific information.

[0217] Location-based enhancements can allow for measurement relaxation (e.g., changes to the timing / frequency of measurements) when the WTRU is within a threshold distance (e.g., represented by the parameter distanceThresh) from a cell reference point (e.g., the cell center of a cell). In some cases, the WTRU can not perform intra-frequency measurements, measurements of the same or lower priority NR inter-frequency cells, or measurements of lower priority inter-RAT frequency cells if any or all of the following conditions are met: the serving cell satisfies Srxlev > S IntrasearchP and Squal > S IntrasearchQ ; the WTRU has valid WTRU location information; and / or the distance between the WTRU and the serving cell reference location is shorter than distanceThresh. For example, Srxlev and S IntrasearchP may be indicated based on intra-frequency measurements. Squal and S intrasearchQ are the intra-frequency measurement-based cell reselection quality values and thresholds, respectively.

[0218] Time-based enhancements can require the WTRU to perform cell reselection measurements in a quasi-terrestrial fixed cell at some time prior to t-Service (although the exact timing can depend on WTRU implementation). The WTRU can perform intra-frequency, inter-frequency, or inter-RAT measurements prior to t-Service regardless of the distance between the WTRU and the serving cell or whether the serving cell satisfies Srxlev > S IntrasearchP and Squal > S IntrasearchQ , or Srxlev > S nonIntrasearchP and Squal > S nonIntransSearchQ .

[0219] These distance and time-based measurement rules can be implemented without impacting the procedures for measurements of NR inter-frequency or inter-RAT frequencies of higher priority. The WTRU can perform measurements of NR inter-frequency or inter-RAT frequencies of higher priority regardless of the remaining service time or distance to the cell reference point.

[0220] NTN for IoT applications are described herein. Many of the Rel-17 enhancements specified for NR NTN can also be applicable for IoT NTN, including: time / frequency pre-compensation; timing advance reporting; timer and monitoring window offset; and / or cell (re)selection enhancements based on t-service. Other enhancements such as disabling HARQ feedback and mobility enhancements are discussed in Rel-18. One enhancement specific to IoT NTN can be to consider the discontinuous coverage scenario.

[0221] Discontinuous coverage scenarios are described herein. Discontinuous coverage in NTN can refer to temporary and predictable coverage gaps that can be caused by non-continuous coverage in NGSO deployments. While not an issue if continuous coverage is globally available, this can not be the case in early NTN deployments or in deep rural areas. Enhancements can be specified for IoT NTN to address the discontinuous coverage scenario, but this has not been addressed in NR.

[0222] Due to deterministic satellite movement, coverage gaps can be predicted and accounted for, and Rel-17 IoT NTN can support additional assistance information (e.g., satellite ephemeris and coverage parameters such as coverage zone radius, cell reference point or elevation angle, and service start time of neighboring cells (which can be given by t-Service start and referred to herein as t-Service start)) to predict the duration of the coverage gap. The WTRU can suspend access stratum functionality while within the discontinuous coverage gap.

[0223] Positioning methods are described herein. In deployments operating according to Rel. 16 specifications, downlink, uplink, and downlink and uplink positioning methods (e.g., RAT dependent positioning methods) can be used. In the following paragraphs, various positioning methods are considered. A “DL positioning method” as referred to herein can refer to any positioning method that uses downlink reference signals such as PRS. A WTRU can receive multiple reference signals from a TP(s) and measure DL RSTD and / or RSRP. Examples of DL positioning methods include DL-AoD or DL-TDOA positioning. An “UL positioning method” as referred to herein can refer to any positioning method that uses uplink reference signals such as SRS for positioning. A WTRU can transmit SRS to multiple RPs and the RPs measure UL RTOA and / or RSRP. Examples of UL positioning methods are UL-TDOA or UL-AoA positioning.

[0224] A “DL and UL positioning method” as referred to herein can refer to any positioning method that uses both uplink and downlink reference signals for positioning. In some examples, a WTRU can transmit SRS to multiple TRPs and the base stations can measure Rx-Tx time differences that are computed based on the time of arrival of DL RS (e.g., PRS). The base stations can measure RSRP of the received SRS. The WTRU can measure Rx-Tx time differences of PRS transmitted by multiple TRPs. The WTRU can measure RSRP for received PRS. The Rx-TX differences and possibly RSRP measured at the WTRU and base stations can be used to compute round trip time. Here, the term “WTRU Rx-Tx time difference” can refer to the difference between the time of arrival of a reference signal transmitted by a TRP and the transmission time of a reference signal transmitted from a WTRU. An example of a DL and UL positioning method can be, for example, multi-RTT positioning.

[0225] Various terms that can be used herein are described as follows. As used herein, the term “network” can include references to AMF, LMF, base station, or NG-RAN. The terms “preconfigured” and “configured” can be used interchangeably herein. “Non-serving base station” and “neighboring base station” can be used interchangeably herein. The terms “base station,” “nodeB,” and “TRP” can be used interchangeably herein. The terms “PRS,” “SRS,” “SRS for positioning,” or “SRS for positioning purposes” can be used interchangeably herein. The terms “PRS” or “PRS resource” can be used interchangeably herein. The terms “PRS(s)” or “PRS resource(s)” can be used interchangeably herein. The aforementioned “PRS(s)” or “PRS resource(s)” can belong to different PRS resource sets. “PRS” or “DL-PRS” or “DL PRS” can be used interchangeably herein. The terms “measurement gap” or “measurement gap pattern” can be used interchangeably herein. The term “measurement gap pattern” can include parameters such as measurement gap duration or measurement gap repetition period or measurement gap periodicity.

[0226] A PRU can be a WTRU or a TRP whose position (e.g., altitude, latitude, geographic coordinates, or local area coordinates, or proximity to another known position) is known to the network (e.g., base station, and / or LMF, or another network entity or device). The capabilities of a PRU can be the same as a WTRU or a TRP. For example, a PRU can be capable of receiving PRS or SRS, or transmitting SRS for positioning, returning measurements, or transmitting PRS. A WTRU that is a PRU can be used by the network for calibration purposes (e.g., to correct for unknown timing offsets, to correct for unknown angular offsets).

[0227] An LMF can be one non-limiting example of a node or entity (e.g., network node or entity) that can be used for positioning or support positioning. It should be understood that any other node or entity can be used in place of an LMF and still be consistent with the present disclosure. A WTRU can receive information from the network (e.g., LMF, base station) indicating a configured or preconfigured threshold(s).

[0228] A line-of-sight (LOS) indicator can be a hard indicator (e.g., 1 or 0) or a soft indicator (e.g., 0, 0.1, 0.2…, 1), and can indicate a likelihood of the existence of an LOS path between a TRP and a WTRU or along a PRS. The LOS indicator can be associated with a TRP or PRS resource ID (e.g., index). A WTRU can receive the LOS indicator from the network in association with (i.e., per) a TRP or resource ID. Alternatively, or additionally, a WTRU can determine or derive the LOS indicator per TRP or resource ID based on measurements.

[0229] The following paragraphs describe various issues addressed by the embodiments described herein. In an NTN, the WTRU position may be verified by the network (e.g., LMF, base station) by comparing the reported GNSS / GPS position with the results of one or more NTN-based RAT-related positioning methods (e.g., measurements reported by the WTRU). The WTRU may experience periods of discontinuous coverage or coverage gaps (e.g., no satellite coverage) as described above due to the ephemeris of the NTN satellites.

[0230] Figure 3 is a diagram illustrating an example of discontinuous coverage. Figure 3 The example of an NTN shown may include at least two satellites 310 and 320 and a WTRU 330. The movement of satellites 310 and 320 along different orbital paths over time is shown in three different illustrations 301, 302, and 303. WTRU 330 may be within the coverage area of ​​satellite 310 during times shown as T1, T3, and T5. Illustration 301 shows the positions 310a and 320a of satellites 310 and 320, respectively, at time T1. At time T1, WTRU 330 is within the coverage area of ​​satellite 310, but outside the coverage area of ​​satellite 320 (i.e., experiencing a coverage gap with respect to satellite 320), and therefore may only receive PRS from satellite 310. Illustration 302 shows satellite 310 moving from position 310a to position 310b and satellite 320 moving from position 320a to position 320b at time T2. At time T2, WTRU 330 is within the coverage area of ​​satellite 320, but outside the coverage area of ​​satellite 310 (i.e., experiencing a coverage gap with respect to satellite 320), and thus may only receive PRS from satellite 320. Illustration 303 shows that at time T3, satellite 310 moves from position 310b to position 310c and satellite 320 moves from position 320b to 320c. At time T3, WTRU 330 is within the coverage area of ​​both satellite 310 and satellite 320 and may receive PRS from each satellite.

[0231] During coverage gaps (e.g. Figure 3 301 and 302 ), the WTRU 330 may move. In this case, due to unavailable or inaccurate satellite-based RAT-dependent positioning (e.g., the WTRU cannot see enough satellites / collect enough measurements to perform positioning), the network may not be able to verify the WTRU's location, and this inability to verify the WTRU's location may affect service continuity. The NW needs a solution to consistently verify the WTRU's location.

[0232] Content of reporting for WTRU location validation is described herein. In some examples, during or before location validation, a WTRU can determine to send measurements to be made on received PRS and a reference location (e.g., WTRU location determined from GNSS / GPS) to the network. The WTRU can determine to make the measurements according to a configured / determined RAT-dependent positioning method (e.g., a method such as DL-TDOA, RTT, DL-AoD). The network can determine the location of the WTRU based on the reported measurements and cross-check with the reported reference location (e.g., WTRU’s location determined from GNSS / GPS-based positioning method). If the WTRU location determined from the reported measurements is within a threshold from the reference location, the network can determine that the reported location of the WTRU is valid and the network can provide services (e.g., call, data service, and / or continuity of RRC CONNECTED state) to the WTRU.

[0233] In some examples, a WTRU can send a report containing various contents to the network. The contents of the report can include measurements on RAT dependent positioning methods on PRS transmitted from TRPs / TPs (e.g., satellites, HAPS, mobile IAB or other mobile and / or space-based network nodes). Such measurements can be performed using metrics such as RSRP, RSTD, ToA, WTRU Rx-Tx time, AoA, and / or AoD. The contents can include timestamp(s) when the measurements are made, where the timestamp can be expressed in absolute (e.g., UTC) / relative time with respect to a reference time. The contents of the report can include the ID (e.g., index) of the TRP / TP (e.g., satellite) from which the WTRU receives the PRS(s) and / or on which the WTRU performs the measurements on the received PRS(s). The contents of the report can include the index (e.g., PRS resource ID) of the PRS resource that the WTRU measures. The contents of the report can include a LOS / NLOS indicator, which can include a hard value (e.g., 1 or 0) or a soft value (e.g., 0, 0.1, 0.2, …, 1) indicating the likelihood of LOS / NLOS. The contents of the report can include a reference location, such as an estimate of the WTRU location obtained from GPS / GNSS and / or sensors. The contents of the report can include timestamp(s) indicating when the estimate of the WTRU location using GPS / GNSS is obtained. The contents of the report can include information indicating the uncertainty related to the measurement / estimate of the WTRU location, where the uncertainty is expressed in range or standard deviation (e.g., in units of meters / km, seconds, degrees, number of symbols, dBm, dB). The contents of the report can include information referencing one or more TRPs / TPs / PRS on which RSTD is computed. The contents of the report can include information referencing the reference PRS index (e.g., ID) on which RSTD is computed.

[0234] A WTRU can report at least one of the above measurements / information / contents to the network based on a request from the network. In some examples, a WTRU can determine to report the measurements made on the received PRS and the location information obtained from GNSS at a validation occasion.

[0235] A validation occasion and an actual validation occasion can be defined as follows. A validation occasion can be an occasion at which a WTRU is configured to report a location estimate obtained according to a RAT dependent positioning method and GNSS positioning. An actual validation occasion can be defined as an occasion at which a WTRU reports a location estimate obtained according to a RAT dependent positioning method and GNSS positioning.

[0236] In some examples, the WTRU may be configured to perform measurements at a preconfigured time, which is expressed in time units (e.g., symbol / time slot / frame / second) before the opportunity. For example, the WTRU may be configured to perform measurements N time slots before the verification opportunity. The preconfigured time may be based on the WTRU's capabilities. If the WTRU is unable to perform measurements according to the configured TRP or the minimum number of TRPs (e.g., satellites), the WTRU may not send a report to the network.

[0237] In some examples, the WTRU may receive configuration information for a validation window, where the configuration information includes one or more parameters. The one or more parameters may include a start time expressed in time units (e.g., absolute time, relative time relative to a reference time, symbol / time slot / frame index). The reference time may be based on an occasion / event, such as transmission / reception of a message to / from the network, transmission of one or more messages that may be used in a RACH procedure (e.g., msg1 / msg3 / msgA), and / or reception of one or more messages that may be used in a RACH procedure (e.g., msg2 / msg4 / msgB). The one or more parameters may include an end time expressed in time units (e.g., absolute time, relative time relative to a reference time, symbol / time slot / frame index). The one or more parameters may include a duration of the window expressed in time units (e.g., seconds, hours, symbols, time slots, frames).

[0238] The configuration information for the verification window may be received via one or more of: system information (e.g., within SIB19, SIB31, SIB32); RRC signaling; LPP messages; one or more MAC CEs; or any other logically equivalent messages. In some examples, the WTRU may receive the configuration information in multiple messages. For example, the WTRU may receive an initial default configuration via a first message (e.g., via system information) and then receive a dedicated configuration or configuration information via a second message (e.g., via RRC configuration). The WTRU may prioritize the configuration provided via the dedicated configuration.

[0239] In some examples, the WTRU may determine parameters related to WTRU location verification (e.g., period of verification occasions, start / end times of verification windows) based on one or more broadcast transmissions (e.g., SIBs) from the network, wherein the network may associate RACH occasions with the parameters related to WTRU location verification. The WTRU may send a preamble associated with the RACH occasion. The WTRU may receive information indicating the association between the preamble sequence and the RACH occasion via one or more messages broadcast by the network (e.g., SIBs). In some examples, the WTRU may be pre-configured with the association by the network.

[0240] During a validation window, the WTRU can determine to perform WTRU position validation at a configured periodic occasion. The periodicity of the occasion can be configured by the network and / or determined by the WTRU.

[0241] The WTRU can receive an activation / deactivation command for the validation window from the network (e.g., LMF, base station) via, for example, LPP message, RRC, MAC-CE, DCI, or any other logically equivalent signaling. The WTRU can send a request to activate or deactivate the validation window.

[0242] The configuration information for the validation window can be specific to a cell and / or network node (e.g., satellite or base station). Unless otherwise indicated (e.g., upon receiving further configuration information (e.g., second configuration) or deactivation command), the WTRU can apply the received configuration or received configuration information for the duration of the connection to the cell and / or network node. If the WTRU is no longer connected to the cell and / or network node, the WTRU can assume that the configuration information is no longer valid. The WTRU can then, for example, apply a default configuration information, apply a second configuration (e.g., received in a HO command or system information originating from a new cell / network node), or deactivate the validation.

[0243] Embodiments of configuration for RAT-dependent positioning methods are described herein. The WTRU can receive a configuration, configuration information, and / or assistance information (e.g., PRS resource index (ID), PRS resource set ID, frequency layer index, bandwidth, PRS configuration information for measurements) for a RAT-dependent positioning method for obtaining measurements of PRS. The WTRU can determine the positioning method based on the configuration information received from the network (e.g., base station, LMF). The WTRU can determine to use the positioning method for a previous occasion (e.g., last occasion) for measurements for WTRU position validation.

[0244] The WTRU can determine to use a positioning method for WTRU position validation based on the configuration or assistance information received from the network. For example, the WTRU can determine the positioning method for WTRU position validation based on the number of satellites configured for the WTRU. For example, if the assistance information contains ephemeris information for one satellite, or the configuration indicates to use one satellite, the WTRU can determine to use an RTT positioning method. In some examples, if the WTRU is configured with more than one satellite, the WTRU can determine to use a DL-TDOA-based positioning method.

[0245] In some examples, if the WTRU determines that only one satellite is observable based on ephemeris information and / or determines the WTRU’s location based on GNSS, the WTRU can determine that a positioning method requiring one satellite (e.g., RTT-based positioning method) is needed. If the WTRU determines that more than one satellite is observable based on, for example, the remaining duration within the window (e.g., the window defined by the parameter t-service), one or more cell reference points (one or more), one or more satellite ephemeris, and / or the WTRU’s location determined based on GNSS, the WTRU can determine a positioning method that can use measurements made on more than one satellite (e.g., DL-TDOA, DO-AoD).

[0246] In some examples, the WTRU can be configured or preconfigured with rules associating a minimum number of TRPs (e.g., satellites) and positioning methods (e.g., four for DL-TDOA, one for RTT-based positioning method). Based on the configured or preconfigured rules, the remaining duration within the window for service in the current area (e.g., the window defined by the parameter t-service), one or more cell reference points (one or more), and / or one or more satellite ephemeris and / or WTRU location determined based on GNSS, the WTRU can determine a positioning method.

[0247] In some examples, the WTRU can be configured with more than one positioning method (e.g., DL-TDOA and DL-AoD, DL-AoD and RTT-based positioning method). Based on the remaining duration within the window for service in the current area (e.g., the window defined by the parameter t-service), one or more cell reference points (one or more), and / or one or more satellite ephemeris and / or WTRU location determined based on GNSS, the WTRU can determine to use more than one positioning method (e.g., a combination of DL-TDOA and DO-AoD) for determining the WTRU’s location.

[0248] A WTRU can determine the TRP (e.g., satellite) to use based on ephemeris information and / or WTRU position determined based on GNSS. The WTRU can use one or more criteria to select a TRP. One criterion can be that the RSRP of a PRS measured from a TRP is above (or equal to) a threshold, which can be configured or preconfigured. Another criterion can be that a soft / hard LOS indicator associated with a TRP is above (or equal to) a preconfigured threshold for a soft LOS indicator, e.g., a soft LOS indicator can take values of [0, 0.1,... 0.9, 1] and a hard LOS indicator can be 1 or 0. Another criterion can be that an uncertainty level related to a measurement (e.g., TDOA, ToA, AoA, AoD, WTRU Tx-Rx time) is below (or equal to) a configured or preconfigured threshold. Another criterion can be that an uncertainty level related to an expected measurement (e.g., expected TDOA, expected ToA, expected AoA, expected AoD, expected WTRU Rx-Tx time) is below (or equal to) a preconfigured threshold. Another criterion can be the remaining duration within a window for service (e.g., a window defined by parameter t-service) within the current area of a cell originating from a TRP. Another criterion can be whether the start of a window for service within the current area of a current serving cell overlaps with a window for service within a neighboring cell (e.g., whether there is a discontinuous coverage). Another criterion can be the distance from the WTRU to a cell reference point originating from a TRP.

[0249] In some examples, a WTRU can be configured or preconfigured to use only satellites with certain characteristic(s) for a given positioning method. For example, a WTRU can use only satellites for certain methods, e.g., DL-TDOA, multi-RTT, or DO-AoD methods, that have one or more of the following characteristics: GEO or LEO classification; a particular orbital height or range of orbital heights; movement at a given speed or range of speeds; movement in a particular direction or range of directions; utilize earth-fixed or earth-moving beams; or have a particular beam / cell diameter or range of diameters.

[0250] A WTRU can be configured with a default positioning method. The default positioning method can be configured, e.g., by the network. The WTRU can determine to use the default positioning method if one or more conditions are met. A condition can be that the WTRU cannot observe a minimum number of satellites for a configured positioning method (e.g., RSRP of a PRS transmitted from a satellite is below a threshold) (e.g., the minimum number of satellites required for positioning if the WTRU is configured with DL-TDOA can be four). A condition can be that the WTRU does not receive assistance information / configuration for a positioning method. A condition can be that the WTRU is instructed to use the default positioning method.

[0251] If the WTRU cannot determine any positioning method (e.g., due to no visible satellites), the WTRU can determine to send an indicator / message to the network via RRC, LPP message, MAC-CE, UCI to indicate that the WTRU cannot perform WTRU location validation. In one example, if the WTRU cannot determine any positioning method due to being in an NTN coverage gap, the WTRU can send the indication, e.g., by switching connection type (e.g., via a terrestrial network) and / or can wait until the NTN coverage is restored and send the indication to the entering cell. If the NTN coverage remains available, but no suitable satellite / TRP is available for positioning, the WTRU can send the indication to the serving and / or available NTN cell. If the WTRU receives a request from the network to perform WTRU location validation, the WTRU can send the indicator / message.

[0252] Various aspects are described herein in which a WTRU prepares for location validation. In some examples, the WTRU can be configured with or receive configuration information indicating a preparation duration (e.g., K slots). The preparation duration can be used by the WTRU to prepare for measurements / location estimates via GNSS. For example, the WTRU can need or benefit from time to establish synchronization with GNSS / GPS navigation satellites. The WTRU can need to establish synchronization with a TRP / satellite that can transmit one or more PRSs.

[0253] In some examples, when the WTRU reports a determined periodicity to the network (e.g., during random access or WTRU capability transfer), the WTRU can determine to perform WTRU location validation after the preparation duration elapses. In another example, the WTRU can determine the preparation duration based on the WTRU’s capabilities. If the WTRU determines a periodicity from a list of periodicities configured by the network, the WTRU can determine to perform WTRU location validation after the preparation duration elapses.

[0254] The WTRU can receive an ACK / NACK (which can constitute an approval / rejection) for the WTRU determined periodicity of the actual validation occasion. Once the WTRU receives the ACK message, the WTRU can determine that the actual validation can be performed, e.g., when an amount of time equal to the determined preparation duration elapses after receiving the ACK message. In one example, the start time of the preparation duration can be the time at which the WTRU receives the ACK from the network.

[0255] Figure 4 is a diagram illustrating an example of a preparation time in which the actual validation occurs after performing measurements based on received PRS(s). As shown, the WTRU can be in a first satellite (in Figure 4 Figure 4 ​may be located within the coverage area of a second satellite (indicated as satellite #1) at time T2. The WTRU can be located within the coverage area of a third satellite (indicated as satellite #2) at time T4. The WTRU can be located within the coverage area of both satellite #1 and satellite #2 at time T3. Figure 4 may be located within the coverage area of a second satellite (indicated as satellite #1) at time T2. The WTRU can be located within the coverage area of a third satellite (indicated as satellite #2) at time T4. The WTRU can be located within the coverage area of both satellite #1 and satellite #2 at time T3. Figure 4 Further shown, the WTRU can be configured with (or have determined) a preparation duration equal to K slots from T3, when the WTRU is within the coverage of both satellite #1 and satellite #2. The WTRU can apply the preparation duration after the WTRU makes measurements of PRS from both satellite #1 and satellite #2.

[0256] Methods for determining a start time of a validation procedure are described herein. A WTRU can determine a start time of a validation procedure (e.g., a first validation occasion within a set of periodic / semi-persistent validation occasions, or a validation occasion within a set of aperiodic validation occasions) based on one or more events. One event can be that the WTRU receives configuration information from the network regarding the start time of the validation procedure (e.g., a relative time with respect to a reference time (e.g., configured reception), an absolute time).

[0257] Another event can be that the WTRU determines or is configured with a preparation time, and the WTRU determines the start time of the validation procedure based on a reference time (T) and the preparation time (Tp). For example, the start time can be T + Tp. The WTRU can determine the reference time based on at least one of: receiving one or more configuration messages from the network (e.g., via RRC signaling, LPP messages, or any other logically equivalent signaling), receiving an ACK message, or measurements of PRS performed for a minimum number of satellites or for a plurality of configured satellites.

[0258] If the WTRU is configured to use an RTT-based positioning method or an UL-TDOA positioning method, the WTRU can determine the start / end time of the validation procedure based on an SRS configuration configured by the network. For example, the WTRU can determine to start the validation procedure based on a start time of a periodic or semi-persistent SRS transmission. The WTRU can determine to terminate the validation procedure when the network deactivates the semi-persistent PRS transmission by a MAC-CE or another logically equivalent message (or the WTRU deactivates the semi-persistent PRS transmission). The WTRU can send a request to the network to deactivate the SRS transmission. In another example, the WTRU can determine to terminate the validation procedure if the WTRU receives a termination command from the network (via RRC signaling or other logically equivalent signaling).

[0259] Methods for determining success or failure of WTRU location verification are described herein. In some examples, a WTRU can determine that WTRU location verification is successful when the WTRU receives a message from the network after the WTRU sends a report containing information for WTRU location verification (e.g., a measurement report, a WTRU location determined by a GNSS / GPS based method). The WTRU can determine that WTRU location verification is successful based on one or more conditions. One condition can be receiving a message indicating that the WTRU location is verified. One condition can be receiving authorization from the network for a request from the WTRU that requires WTRU location verification (e.g., requesting to make a call, transition to RRC CONNECTED / RRC INACTIVE state, and / or maintain RRC CONNECTED state). For example, the WTRU can make a request to make a call. The WTRU can send a report containing information for WTRU location verification. In response to the request, the WTRU can receive authorization from the network to make the call. In another example, the WTRU can make a request to transition to RRC INACTIVE state. The WTRU can send a report containing information for WTRU location verification. In response to the request, the WTRU can receive authorization from the network to transition to RRC INACTIVE state.

[0260] The WTRU can determine that WTRU location verification fails based on one or more conditions. One condition can be receiving a message indicating that the WTRU location fails. One case can be that the WTRU does not receive authorization from the network for a request from the WTRU that requires WTRU location verification (e.g., requesting to make a call, transition to RRC CONNECTED / RRC INACTIVE state, maintain RRC CONNECTED state) within a preconfigured time from the time the WTRU sends a report containing measurements and WTRU location determined from GNSS / GPS.

[0261] Methods for determining success or failure of a WTRU location validation procedure are described herein. In some methods, a WTRU can determine that a validation procedure is successful if the WTRU determines an actual validation occasion, takes reporting measurements, and / or sends a measurement report at the actual occasion. In some examples, a WTRU can determine that a validation procedure is successful according to one or more criteria. One criterion can be that the WTRU takes measurements based on PRS from a configured and / or minimum number of TRPs (e.g., satellites) and / or determines its location based on GNSS / GPS before a preconfigured time before the actual validation occasion. Another criterion necessary for a successful location validation procedure can be that the WTRU sends a report containing information required for WTRU location validation (e.g., measurements taken on one or more PRS and / or WTRU location determined from GNSS / GPS) at the actual validation occasion. Another criterion can be that the WTRU determines an actual validation occasion if the WTRU receives a request from a network to determine a validation occasion. Another criterion can be that the WTRU determines an actual validation occasion if the WTRU receives a request from a network to determine a validation occasion during a specified time interval / duration (e.g., a time limit for determining a validation occasion).

[0262] Various outcomes of a WTRU location validation or a WTRU location validation procedure failure are described herein. In some examples, if a WTRU location validation or validation procedure fails, the WTRU can make one or more determinations. One determination can be that the WTRU will transition to an idle state. In this case, the WTRU can determine to perform an initial access procedure to attempt to establish a connection to a network. Another determination can be that the WTRU receives a rejection message associated with a service (e.g., a call) to which the WTRU is subscribed. Another determination can be that the WTRU is barred from performing UL transmission(s) and / or performing an initial access procedure (e.g., the WTRU can not receive a grant for UL transmission). The barring of UL transmission(s) or initial access can be set for a preconfigured time (e.g., N frames / slots / symbols / seconds). Another determination can be that the WTRU sends a request after a preconfigured time (e.g., N frames / slots / symbols / seconds) after the WTRU sends a request. Another determination can be that the WTRU receives limited service from a network (e.g., an amount of bandwidth allocated to the WTRU is limited to a preconfigured amount, a modulation / coding rate is limited to a preconfigured set, a configurable frequency range / center frequency is limited to a set).

[0263] Methods for determining TRPs (e.g., satellites) for which to perform position verification are described herein. In some examples, for WTRU position verification, a WTRU can determine the TRP(s) (e.g., satellite(s)) from which to receive PRS based on one or more conditions. If one or more such conditions are met for a particular TRP, the WTRU can determine to perform position verification related to the TRP. One condition can be that the measurement (e.g., RSRP, RSRP per path) of the PRS transmitted from the TRP is above or equal to a preconfigured threshold. Another condition can be that the ToA of the PRS from the TRP is within a configured or preconfigured threshold from the configured verification occasion(s). For example, if the WTRU is configured with periodic verification occasions, each occasion can be within a preconfigured threshold from the ToA.

[0264] Another condition can be the positioning method the WTRU is configured with. For example, if the WTRU is configured with an RTT-based positioning method, the WTRU can determine that the number of satellites to select is at least one. If the WTRU is configured with DL-TDOA, the WTRU can determine that the minimum number of satellites to select is four. The WTRU can determine a set of satellite(s) based on at least one of the aforementioned criteria.

[0265] Another condition can be that the WTRU position is estimated by GNSS / GPS / sensor. The WTRU can determine the satellites to measure based on the WTRU position or the NTN / terrestrial cell with which the WTRU is associated.

[0266] Another condition can be the number of satellites for position verification. For example, the WTRU can be configured with a number / minimum number of satellites to measure PRS from. Based on the configured number of satellites, the WTRU can determine from which satellite to measure.

[0267] Methods for transmitting SRS for WTRU position verification are described herein.

[0268] Figure 5 FIG. 1 illustrates an example process for RTT-based positioning. As shown, a TRP 510 can be configured to transmit PRS(s) and receive sounding reference signals (SRSp) from a WTRU 520 for positioning. The WTRU 520 can be configured to receive PRS(s) from the TRP 510 and transmit SRSp(s) to the TRP 510. As shown, the WTRU 520 can determine the ToA of the PRS from the TRP 510 and the TRP 510 can determine the ToD of the SRSp from the WTRU 520. Figure 5 Figure 5 ​As shown, the TRP 510 sends a PRS transmission at T1. The WTRU 520 may receive the PRS transmitted by the TRP 510 at T2. At T3, the WTRU may transmit an SRSp to the TRP. The WTRU 520 may calculate and / or report T3-T2, which may indicate the time difference between the received PRS and the transmitted SRSp (i.e., the WTRU Tx-Rx time) to the network (e.g., the TRP 510). The network (e.g., the TRP 510) may evaluate the time difference between the transmission of the PRS (by the TRP 510) and the reception of the SRSp (by the TRP 510), which may be referred to as the TRP Tx-Rx time. The TRP 510 may be configured to report the TRP Tx-Rx time to an entity (e.g., the LMF). Additionally, the network (e.g., TRP 510) and / or the WTRU may be configured to determine the RTT by calculating the difference between the TRP Rx-Tx time and the WTRU Tx-Rx time (e.g., by evaluating (T4-T1)-(T3-T2)). The network (e.g., TRP 510) and / or the WTRU may be configured to report the calculated RTT to another entity (e.g., LMF).

[0269] Figure 6 is a diagram illustrating the relationship between satellite position, WTRU position, transmission and reception of PRS, and transmission and reception of SRS (e.g., SRSp). Figure 6 As shown, the satellite may move along an orbital path over time, arriving at positions 610a, 610b, 610c, 610d, and 610e at times T5, T6, T7, T8, and T9, respectively. The coverage area of ​​the satellite 610 may change over time depending on the location of the satellite 610. The WTRU 620 may be within the coverage area during only a portion of the time instance shown, and the ability of the WTRU 610 to receive PRS from the satellite 610 and transmit SRS to the satellite 610 may be affected.

[0270] exist Figure 6 In the example shown, WTRU 620 receives a signal from satellite 610 (located at Figure 6 6 and 8. The WTRU 620 may receive a PRS (shown by element 610a in FIG) and transmit an SRS (e.g., SRSp) to the satellite 610 at T=T6 and T=T8. Basically according to one or more methods described herein, the WTRU 620 may determine the actual verification opportunity during two intervals (e.g., after the WTRU 620 transmits the SRS to the satellite 610). The first interval may be between T6 and T7. The second interval may be between T8 and T9. The WTRU 620 may be configured to transmit the SRSp with a configured repetition factor (e.g., repetition factor = two). Although Figure 6As not explicitly shown in the illustration 601, the satellite 610 can be configured to transmit PRS at T3 and / or T9 (e.g., periodically or aperiodically), but the WTRU 620 can not be able to receive the PRS, e.g., due to NLOS.

[0271] In some examples, the WTRU can determine a successful WTRU location validation based on at least one of the conditions or a combination of the conditions. One condition can be that the WTRU is configured with a grant (e.g., configured or dynamic grant) to transmit SRS and / or send a measurement report to the network before a time limit (e.g., a preconfigured time before the actual validation occasion). The measurement report can include at least the WTRU Tx-Rx time. Another condition can be that the WTRU is configured with one or more grants (e.g., configured or dynamic grants) to transmit SRS at configured repetition occasions and / or at a minimum / required number of repetition occasions. Another condition can be that the WTRU is configured with a grant (e.g., configured or dynamic grant) to send a measurement report to the network before a time limit (e.g., a preconfigured time before the actual validation occasion). Another condition can be that the WTRU is configured with a grant (e.g., configured or dynamic grant) within a preconfigured threshold (e.g., expressed in time units such as seconds, symbols, slots, frames) from the time the WTRU receives the PRS. For example, referring to the example shown, if T3-T2 is greater than the preconfigured threshold, the WTRU can determine that the WTRU location validation is not successful. Another condition can be that the WTRU transmits SRS at a scheduled grant / occasion. The WTRU can transmit SRS at the scheduled grant / occasion. If the WTRU is configured (e.g., by the network) with a higher priority level for SRS compared to other channels, the WTRU can determine to transmit SRS first when the collision(s) between SRS resources and other channels (e.g., time / frequency resources of PUCCH / PUSCH and time / frequency resources of SRS) overlap. Figure 6

[0272] ​In some examples, the WTRU can determine that a failure in verifying the location has occurred when the WTRU is unable to transmit the SRS prior to the configured time before the actual verification. In this case, the WTRU can not be provided with a grant / occasion by the network to transmit the SRS. In another example, if the transmission of other channels (e.g., PUCCH, PUSCH) is associated with a higher priority than the SRS, the WTRU can need to prioritize the transmission of the other channels (e.g., PUCCH or PUSCH). In this case, the WTRU can cancel one or more SRS transmissions. When the WTRU declares a failure in the location verification, the WTRU can skip to the next verification occasion for reporting. Alternatively, or additionally, the WTRU can send a report to the network that the WTRU location verification failed due to the cancellation / postponement of the SRS transmission.

[0273] During the validation window, the WTRU can determine the priority level of the SRS resource or transmission according to the configuration information provided from the network. For example, the WTRU can determine that the SRS transmitted during the validation period is higher than other channels (e.g., PUCCH, PUSCH). Thus, in the case of a conflict (e.g., the time / frequency resources of PUCCH overlap with the time / frequency resources of SRS), if the priority of the SRS transmission is higher than the other channels, the WTRU can determine to prioritize the one or more SRS transmissions.

[0274] Measurements for WTRU verification are described herein. The WTRU can make M measurements of PRS prior to the actual verification occasion. Similarly, the WTRU can transmit SRS at N occasions prior to the actual verification occasion. The WTRU can determine to report the M measurements at each actual occasion, or the WTRU can determine to process (e.g., average) the M measurements and report the processed measurements to the network.

[0275] Examples of PRS / SRS configuration are described herein. In some examples, a PRS configuration can contain or provide one or more parameters. Such parameters can include a number of symbols, a transmission power, a number of PRS resources included in a PRS resource set, a muting pattern for PRS (e.g., the muting pattern can be expressed via a bitmap), a periodicity, a type of PRS (e.g., periodic, semi-persistent, or aperiodic), a slot offset for periodic transmission of PRS, a vertical shift in the frequency domain for PRS pattern, a time gap during repetition, a repetition factor, a resource element (RE) offset, a comb pattern, a comb size, a spatial relation, QCL information for PRS (e.g., QCL target, QCL source), a number of PRUs, a number of TRPs, an absolute radio frequency channel number (ARFCN), a subcarrier spacing, an expected RSTD, an uncertainty in the expected RSTD, a starting physical resource block (PRB), a bandwidth, a BWP ID, a number of frequency layers, a start / end time of PRS transmission, an on / off indicator for PRS, a TRP ID, a PRS ID, a cell ID, a global cell ID, a PRU ID, and an applicable time window. A WTRU can apply a PRS configuration or PRS configuration information, for example, if the current time is within the applicable time window.

[0276] In some examples, a configuration for SRS positioning (SRSp) or SRS configuration can include one or more of the following: a resource ID; a comb offset value, a cyclic shift value; a starting position in the frequency domain; a number of SRSp symbols; a shift of SRSp in the frequency domain; a frequency hopping pattern; a type of SRSp (e.g., aperiodic, semi-persistent, or periodic); a sequence ID used to generate a SRSp sequence, or other ID used to generate a SRSp sequence; spatial relation information indicating which reference signal (e.g., DL RS, UL RS, CSI-RS, SRS, DM-RS) or SSB (e.g., SSB ID, cell ID of SSB) the SRSp is spatially related to, where the SRSp and the DL RS can be spatially aligned; QCL information (e.g., QCL relationship between the SRSp and other reference signal(s) or SSB); a QCL type (e.g., QCL Type A, QCL Type B, QCL Type D); a resource set ID; a list of SRSp resources in the resource set; transmission power related information; path loss reference information, which can contain an index for SSB, CSI-RS, or PRS; a periodicity of SRSp transmission; and / or spatial information such as spatial direction information (e.g., beam information, transmission angle) of SRSp transmission and / or spatial direction information (e.g., beam ID for receiving DL RS, angle of arrival) of DL RS reception.

[0277] Common principles and observations applicable to the proposed solutions are described herein. The solutions described herein can be based on the principle that a WTRU can periodically observe a satellite according to its ephemeris and the WTRU can determine a verified timing based on the ephemeris. The WTRU can also predict intervals during which the WTRU can not be able to make measurements on PRS. In addition, one or both of the network / WTRU can determine a verification occasion based on the ephemeris information. The WTRU can report its location information determined based on GNSS information, which the network can use to determine a verification occasion.

[0278] Common benefits applicable to the proposed solutions are described herein. Using one or more of the proposed solutions, the network is able to consistently and securely verify the location of a WTRU so that the network can securely provide services to the WTRU even in the presence of discontinuous coverage.

[0279] Various solutions to at least the above problems are described herein. Event-based verification can be one such solution for location verification. The network can provide configuration information for implementing network verification of a WTRU location using RAT-dependent positioning in advance (e.g., when the WTRU initially performs or requests registration at an NTN).

[0280] In some examples, a WTRU can determine to report measurements on RAT-dependent positioning methods and / or GNSS location based on one or more conditions. Such WTRU positioning trigger conditions can be understood as follows. Some cases can involve a trigger based on call origination. For such cases, the WTRU can initiate RAT-dependent positioning if some or all of the following conditions are met. Such conditions can be that the WTRU’s PCell is an NTN cell, the WTRU has a stored RAT-dependent positioning configuration, or the WTRU’s user initiates a call.

[0281] With respect to the case that the WTRU’s PCell is an NTN cell, the WTRU can determine that the PCell is an NTN cell, for example, via detection of NTN-specific system information blocks (e.g., SIB19, SIB31, SIB32), explicit indication, and / or detection of other NTN-specific information (e.g., satellite ephemeris, t-service, pre-compensated timing information, cell reference point).

[0282] Regarding the case where the WTRU has a stored RAT-related positioning configuration, the RAT-related positioning configuration of the WTRU position for NW verification may be provided, for example, by system information (e.g., as part of an existing SIB (such as an NTN SIB) or via a completely new SIB), a RACH message (e.g., MSG2, MSG4, or MSGB), a MAC CE, a dedicated RRC message, or other logically equivalent signaling, where the signaling may be sent when the WTRU moves to NTN coverage (i.e., the WTRU's PCell changes from a TN cell to an NTN cell), for example, the dedicated RRC message may be a handover message (such as an RRCReconfiguration message), which may include target NTN cell information.

[0283] In the case of a WTRU user-initiated call, a "call" may refer to a mobile-originated call (MO call), a mobile-terminated call (MT call), or a data communication call, which may be used to exchange user data between a specific application operating on the WTRU and a peer entity of the application. In some examples, when the WTRU attempts to establish a call, initiates a call, or before making a call, the WTRU may initiate an initial access procedure (e.g., sending a preamble, Msg1, MsgA, or another message related to accessing the network) to establish a connection with the network. The WTRU may also indicate to the network the content of the call (e.g., voice / data / video).

[0284] Some situations may involve other mobility event triggers. For these situations, the WTRU may initiate RAT-dependent positioning if some or all of the following conditions are met. Such conditions may be that the WTRU's PCell is an NTN cell, the WTRU has stored RAT-dependent positioning configuration, and specific mobility event criteria are met.

[0285] Regarding the case where the WTRU's PCell is an NTN cell, the WTRU can determine that the PCell is an NTN cell, for example, through detection of NTN-specific system information blocks (e.g., SIB19, SIB31, SIB32), explicit indication, or detection of other NTN-specific information (e.g., satellite ephemeris, t-service, pre-compensated timing information, cell reference point).

[0286] In case the WTRU has stored RAT-dependent positioning configuration, the RAT-dependent positioning configuration for NW verification of the WTRU location can be provided, for example, through system information (e.g., as part of an existing SIB (e.g., NTN SIB) or via a brand new SIB), a RACH message (e.g., Msg2, Msg4, MsgB, or another message related to access), a MAC CE, through a dedicated RRC message, or through another logically equivalent message, where the RAT-dependent positioning configuration can be sent when the WTRU moves into NTN coverage (i.e., when the PCell of the WTRU changes from a TN cell to an NTN cell). For example, the dedicated RRC message can be a handover message such as an RRCReconfiguration message, which can include information for handover to or communication with a target NTN cell.

[0287] The RAT-dependent positioning configuration can be in conjunction with the above-mentioned triggering condition that meets a certain mobility event criterion (i.e., where the configuration specifies that the WTRU is to initiate RAT-dependent positioning). For example, the configuration can stipulate that the WTRU is to initiate RAT-dependent positioning if the WTRU moves X km (e.g., 5 km) from the location where the WTRU last performed positioning.

[0288] In some examples, “performing RAT-dependent positioning” can mean that the WTRU is to perform RAT-dependent positioning with respect to a TRP (e.g., a satellite (such as a Figure 2measurements to the network (e.g., LMF, base station). The WTRU can receive configuration information for aperiodic / semi-persistent / periodic occasions to report measurements to the network. The occasions can be defined by the timing at which the WTRU reports measurements. For example, the timing for reporting measurements can be defined by an absolute / relative time indication or by a symbol / slot / frame index. The WTRU can receive configuration information (e.g., relative timing information) for periodic occasions for measurement reporting / performing measurements. The WTRU can receive configuration information for semi-persistent reporting / measurement of received PRS, and the configuration information can indicate a start / end time and / or duration (e.g., expressed in number of seconds / symbols / slots / frames) for reporting / performing measurements. Alternatively, or additionally, the WTRU can receive an indication of a time window during which the WTRU is to perform measurements on PRS. In some cases, the WTRU can receive information indicating a reporting period (e.g., expressed in number of symbols / slots / frames). The WTRU can receive an activation / deactivation command for semi-persistent reporting / measurement. The WTRU can send one or more requests to activate / deactivate semi-persistent reporting / measurement. For periodic measurement reporting / performing measurements, the WTRU can receive configuration information related to a reporting period (e.g., expressed in number of symbols / slots / frames), for example, via higher layer messages (e.g., RRC, LPP) or other logically equivalent messages.

[0289] In some examples, the WTRU can receive configuration information for transmitting SRS for performing RAT-dependent positioning. If the WTRU is not configured with the necessary information (e.g., SRS configuration) for transmitting SRS, the WTRU can send an indication to the network that the WTRU is unable to perform WTRU position verification. If the WTRU is not provided one or more SRS configurations, the WTRU can determine to send an SRS configuration request to the network. Alternatively, or additionally, if the WTRU is not configured with an SRS configuration, the WTRU can determine to use a positioning method that does not require transmitting SRS (e.g., DL-TDOA, DL-AoD).

[0290] In some examples, the conditions for performing positioning measurements (e.g., RAT-dependent positioning (GNSS)) can be associated with a scheduling location time (SLT) occasion. The SLT occasion can correspond to one or more reference time occasions that can be configured in the WTRU by the network via LPP or RRC signaling, possibly for network verification of the WTRU location. The WTRU can be configured to monitor the SLT occasion and subsequently perform positioning measurements and / or report the measurements for network verification. For example, the SLT occasion can overlap with a verification occasion, possibly when the SLT is configured in the WTRU by any of the CN or RAN entities (e.g., base station, LMF, AMF, SMF, OAM) in the network. Alternatively or additionally, the SLT occasion can be independent of or outside of the verification occasion, possibly when the SLT occasion is configured by the LCS client / application.

[0291] The SLT occasion can be defined by different parameters, including the SLT type (e.g., periodic, semi-persistent), SLT configuration ID / index, periodicity, number of occasions, starting offset slot, duration per occasion (e.g., number of symbols / slots), and / or total duration / window. The WTRU can be configured with one or more sets of SLT occasions, and any of these sets can be defined by different parameters (e.g., a periodicity of 100 ms can be used for SLT set 1 and a periodicity of 1 s can be used for another SLT set 2). The WTRU can receive an activation / deactivation indication (e.g., in RRC signaling, MAC CE, DCI, or other logically equivalent message) when any of the SLT sets are activated / deactivated.

[0292] As described above, with respect to the conditions for satisfying the particular mobility event criteria for the WTRU to initiate RAT-dependent positioning, the particular mobility event criteria can be defined by one or more events / incidents. One event can be that the WTRU moves a particular distance (e.g., 5 km) from a particular point (e.g., the point at which the WTRU last performed RAT-dependent positioning). In some examples, the WTRU can be configured with a threshold, and the WTRU can determine that the difference (i.e., distance) between the current WTRU location (e.g., determined by GNSS) and the particular point is greater than the threshold. In some examples, the WTRU can receive configuration information indicating the particular point (e.g., a location of a positioning reference unit, or the current WTRU location).

[0293] Another event can be that the WTRU moves a particular distance (e.g., 5 km) from a particular point (e.g., the point at which the WTRU last performed RAT-dependent positioning), but the distance between the current location and a second or another point is less than a threshold.

[0294] Another event can be that the WTRU moves at a certain speed and a certain amount of time has elapsed since the WTRU last performed a RAT-dependent positioning. The certain speed and / or the certain amount of time can be given, for example, by system information, a dedicated RRC message, or hardcoded in the specification. In some examples, the reference location / time at which the WTRU measures the distance or the time, respectively, can be the location / time / occasion at which the WTRU reports the measurements of the received PRS or performs measurements on the received PRS. In some examples, the reference time can be the time at which the WTRU receives a grant for a service / transmission or receives an ACK / NACK message from the network acknowledging / non-acknowledging the reception of a message (e.g., PUCCH / PUSCH) transmitted by the WTRU. In some examples, the reference time can be the time at which the WTRU enters the RRC CONNECTED mode or establishes a connection with the network.

[0295] Another event can be that the WTRU performs HO (i.e., change of PCell) N times, where N is given, for example, by system information, by a dedicated RRC message (N is a positive integer and it can be set to 1), or other logically equivalent signaling. Another event can be that the WTRU performs a handover from a terrestrial network to a non-terrestrial network (change of PCell). Another event can be that the WTRU performs a handover to a cell originating from or associated with a different satellite gateway (i.e., change of PCell). Another event can be that the WTRU performs a handover from a cell originating from or associated with one satellite to a cell originating from or associated with another satellite (i.e., change of PCell).

[0296] Another event can be that the WTRU performs a handover to a cell originating from or associated with a different satellite constellation (i.e., change of PCell). Different satellite constellations can include, for example, satellites belonging to different orbits, altitudes, categories (GEO vs. LEO), or directions. The WTRU can determine that the satellites belong to different constellations, for example, via differences in ephemeris data or based on explicit indications.

[0297] Another event can be that the WTRU performs a handover to a cell providing coverage after a discontinuous coverage gap (i.e., change of PCell). The WTRU can determine that the cell provides coverage after a discontinuous coverage gap, for example, based on an explicit indication (e.g., provided in the HO command), based on a temporary absence of coverage, or based on detecting a gap between a coverage window of a previous serving cell (e.g., represented by parameter t-service) and the start of coverage of an incoming serving cell (i.e., represented by parameter t-service start).

[0298] In some examples, the WTRU can determine the timing of the validation occasion based on the type of event. For example, the WTRU can be preconfigured with information such as a mapping table / configuration that associates events and a maximum / minimum duration after the event during which the WTRU can be expected to perform WTRU location validation. The WTRU can determine the validation occasion based on the duration and ephemeris. For example, if the WTRU moves a certain distance above a threshold (e.g., 50 km), the WTRU can be configured to perform WTRU location validation within 5 hours after the mobility event (e.g., after the WTRU moves more than 50 km threshold). Based on the ephemeris information, the WTRU can determine the validation occasion, which can occur within 5 hours after the mobility event.

[0299] Methods are described herein that are performed when the WTRU fails to complete the validation procedure. If the WTRU is unable to perform location validation within the configured duration from the event, the WTRU can perform one or more actions. In some examples, the WTRU can change RRC state, such as changing to RRC idle or inactive state. The WTRU can perform such actions autonomously (e.g., without prior notification to the network) or can alternatively indicate to the network that the validation procedure has failed. The WTRU can then monitor for a network response, such as an RRC release message or RRC release with suspend indication. In some examples, the network can provide an indication of an additional duration for the WTRU to complete the validation request before releasing the WTRU. This can be implemented, for example, by providing a time to trigger indication along with the RRC release or RRC release with suspend message.

[0300] In some examples, if the WTRU is unable to validate the WTRU location, the WTRU can remain connected; however, the WTRU can be limited on the types of transmissions it can perform. For example, the WTRU can only transmit one or more types of transmissions. Some transmissions can include information related to connection maintenance (e.g., measurement results, measurement reports). Some transmissions can include HARQ feedback (e.g., ACK / NACK of received data) or HARQ retransmissions (e.g., based on reception of retransmission grants). Some transmissions can be RACH (e.g., preamble transmission, Msg3, Msg5, or MsgA) transmissions or otherwise related to random access. Scheduling requests can be another type of transmission.

[0301] Some transmissions can carry data from a subset of logical channels. For example, the WTRU can be limited to transmitting data only to high priority logical channels. Some transmissions can carry emergency related messages (e.g., related to CMAS, ETWS, or emergency calls).

[0302] If the WTRU falls back to RRC IDLE / INACTIVE state, the WTRU can attempt to re-acquire the necessary configuration and measurements to perform WTRU location verification. The WTRU can then attempt to resume connection and can indicate the reason for the previous connection failure was based on location verification failure during RACH. For example, the WTRU can indicate the reason via a new connection establishment / resume cause, dedicated preamble selection, or in a RACH message (e.g., Msg3, Msg5, or MsgA).

[0303] In some examples, the network can bar the WTRU from entering a cell if the WTRU fails one or more verification attempts or if the verification procedure is not performed in time. Examples of barring the WTRU from entering a cell can be when the WTRU fails to connect to a cell (e.g., initial access failure) and / or the cell does not support the WTRU class (e.g., reduced capability WTRU) or features (e.g., non-terrestrial network access) within a configured amount of time (e.g., N hours). The barring can be conditional depending on whether the WTRU has performed WTRU location verification (e.g., has performed the measurements necessary to complete verification) and if so, the WTRU can re-enter the cell.

[0304] In an example procedure, the WTRU can perform the following event-based verification. In a first step, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, configuration information for RAT-dependent positioning methods (e.g., PRS and / or SRS configuration), or thresholds) from the network (e.g., LMF, base station) and keep the configuration. In a second step, the WTRU can perform a RAT-dependent positioning method based on the stored (provided in step 1) RAT-dependent positioning configuration, e.g., when certain conditions are met. The certain conditions can be one or more of: a user of the WTRU initiates a mobile originated call (MO call); the WTRU receives a paging message for a mobile terminated (MT) call; the WTRU’s serving NTN cell is changed; and / or the WTRU determines that the WTRU has moved a certain distance, which can exceed a threshold provided in step 1, for example.

[0305] In a third step, the WTRU can report the location determined by the RAT-dependent positioning method and / or measurement reports (e.g., RSTD, RSRP, WTRU Rx-Tx time for DL-TDOA) when the information becomes available. The WTRU can initiate a certain service (e.g., MO call, MT call, or user data transmission request). If applicable, the WTRU can transmit SRS to the TRP (e.g., satellite). In the same report (or a different report), the WTRU can include a location estimate determined by a GNSS-based method.

[0306] In some examples, the WTRU can receive an indication of a minimum number of satellites for measurement from the network. In some examples, the WTRU can determine a time limit for validation occasion (e.g., time limit relative to a mobility event) based on an amount of distance that exceeds a threshold. For example, if the WTRU moves more than 100 km over the threshold, the WTRU can determine that the time limit for validation occasion is 1 hour. If the WTRU moves more than 20 km over the threshold, the WTRU can determine that the time limit for validation occasion is 6 hours.

[0307] In some example procedures, the WTRU can perform a mobility event based validation based on the time limit. If the WTRU determines that it has moved further than a configured threshold, the WTRU can determine that it should perform a WTRU location validation. In these procedures, the location validation must be performed within a time limit from the mobility event. Otherwise, the WTRU can need to perform an initial access to establish a connection with the network.

[0308] In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, configuration information for RAT dependent positioning methods) from the network (e.g., LMF, base station), first and second thresholds (e.g., expressed in meters and hours, respectively). In one or more steps of the procedure, the WTRU can detect that it has moved a certain distance that exceeds the first threshold from a reference point (e.g., a reported location at a previous reporting occasion, a cell center). The detected movement can constitute a detected mobility event. In one or more steps of the procedure, the WTRU can determine a validation occasion based on the received ephemeris information. If the determined validation occasion is within the second threshold from the time of the detected mobility event, the WTRU can transmit validation information to the network at the determined validation occasion. The validation information can include: a location determined when the information becomes available, e.g., by a RAT dependent positioning method, a location estimate obtained from a GNSS based method, and / or a measurement report (e.g., RSTD for DL-TDOA, RSRP). In one or more steps of the procedure, if the determined validation occasion occurs after a preconfigured time from the time of the detected mobility event, the WTRU can perform an initial access to establish a connection with the network.

[0309] In some example procedures, a WTRU can ignore network validation requirements in an emergency situation. In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, configuration information for a RAT-dependent positioning method), first and second thresholds (e.g., expressed in meters and hours, respectively) from a network (e.g., LMF, base station, or TRP), and the WTRU can maintain the configuration information. In one or more steps of the procedure, the WTRU can start performing RAT-dependent validation if the WTRU determines that a validation procedure is necessary (e.g., based on an event-triggered, NW-requested). In one or more steps of the procedure, the WTRU can determine that the validation procedure has failed (e.g., the WTRU can be unable to determine an actual validation), and the WTRU can be suspended from performing one or more uplink transmissions (e.g., PUSCH transmissions). In one or more steps of the procedure, the WTRU can detect a need for an emergency call, and the WTRU can ignore the suspension or data and / or cell barring, and can perform the emergency call (e.g., using a PUSCH).

[0310] In some examples, a WTRU can be configured with a priority level for a call. For example, an emergency call can be associated with a higher priority than a data communication call. Based on the priority of the call, the WTRU can determine to make the call (e.g., send a request to the network to schedule resources for the call) even during a period in which the WTRU is barred from making calls.

[0311] In some example procedures, a WTRU can perform a priority-based override of network validation requirements. In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, configuration information for a RAT-dependent positioning method), first and second thresholds (e.g., expressed in meters and hours, respectively) from a network (e.g., LMF, base station, or TRP), and can maintain the configuration. In one or more steps of the procedure, the WTRU can start performing RAT-dependent validation if the WTRU determines that a validation procedure is requested (e.g., based on an event-triggered or network-requested). In one or more steps of the procedure, the WTRU can determine that the validation procedure has failed (e.g., when the WTRU is unable to determine an actual validation), and the WTRU is suspended from performing one or more uplink transmissions (e.g., PUSCH transmissions) for a configured duration (e.g., a configured barring duration). In one or more steps of the procedure, the WTRU can send a scheduling request for an uplink transmission (e.g., a scheduling request) during the barring duration if the WTRU determines that it should perform the uplink transmission with a high priority.

[0312] Methods of WTRU location verification that can be performed prior to a WTRU transitioning to an inactive or idle state are described herein. In such methods, it can be beneficial for a WTRU to maintain a valid WTRU location for as long as possible while the WTRU is in an idle / inactive state. If the WTRU determines that the WTRU location needs to be verified during the idle / inactive state, the WTRU can need to transition to an RRC CONNECTED state, which can consume battery power at the WTRU. Thus, it can be beneficial for a WTRU to perform WTRU location verification prior to the WTRU transitioning to an idle / inactive state.

[0313] In some examples, a WTRU can determine to perform WTRU location verification (e.g., perform measurements and / or transmit measurement reports to the network) when the WTRU changes state (e.g., from RRC CONNECTED to RRC INACTIVE, or from RRC INACTIVE to RRC CONNECTED). For example, once the WTRU determines that the WTRU is transitioning to an RRC INACTIVE state (e.g., the WTRU receives an RRC message (e.g., an RRC release message) from the network, the WTRU can send a request to transition to an inactive state), the WTRU can determine to perform measurements. For example, after the WTRU receives an RRC release message from the network, the WTRU can determine to perform measurements based on one or more received PRSs. The WTRU can determine to send a measurement report to the network after the RRC release message. The WTRU can perform measurements after a DRX mode (e.g., the WTRU can perform one or more measurements during an “on” state of a DRX cycle). In another example, the WTRU can follow a DRX mode (e.g., the WTRU sends a measurement report during an “on” state of a DRX cycle) or use a small data transmission (SDT) method to send a measurement report to the network.

[0314] In some examples, the WTRU can determine a time to transmit a measurement report (e.g., a report containing a GNSS location and measurements) or to perform measurements according to a message received from the network (e.g., if the RRC release message contains a time to perform measurements or to report measurements to the network).

[0315] In some examples, the WTRU can determine a time to transmit a measurement report (e.g., a report containing a GNSS location and measurements) or to perform measurements according to a message received from the network while the WTRU is in an RRC CONNECTED state.

[0316] A WTRU can be provided with dedicated resources to perform a RACH procedure (i.e., transmit RACH) for the purpose of location validation. For example, a WTRU can be configured with a specific preamble or a resume cause to prevent the network from mistakenly transitioning the WTRU to RRC CONNECTED state. In some solutions, if a WTRU performs a RACH procedure to transmit WTRU location information (e.g., PRS measurements) and receives an indication to transition to RRC CONNECTED state, the WTRU can reject the transition and remain in the current state. The capability to reject connection can be enabled / disabled via system information, for example.

[0317] In some examples, if a WTRU determines that the WTRU is in an inactive state, the WTRU can use a SRS configuration configured by the WTRU while the WTRU is in RRC CONNECTED state. In some examples, the WTRU can receive SRS configuration information in an RRC message from the network (e.g., via an RRC RELEASE message).

[0318] In an example procedure, a WTRU can perform location validation prior to entering an inactive state. In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, configuration information for RAT-dependent positioning methods) from the network (e.g., LMF, base station, or TRP). In one or more steps of the procedure, the WTRU can determine one or more validation occasions based on an RRC_Release message from the network, which contains a configuration for validation (e.g., a relative timing of the validation occasion (N slots) and / or a validation confirmation period). In one or more steps of the procedure, the WTRU can perform measurements on PRS. In a fourth step, the WTRU can determine its location based on GNSS. In one or more steps of the procedure, the WTRU can report the measurement results at the network-configured occasions and the WTRU’s location estimated via GNSS. In one or more steps of the procedure, if the WTRU receives an authorization to confirm validation, the WTRU can enter an inactive state and determine that the WTRU location is valid for the confirmation period. Otherwise, the WTRU determines to enter an idle state.

[0319] Priority rules applicable to WTRU location validation are described herein. In some examples, a WTRU can be configured with a priority level for measurements for WTRU location validation. If the WTRU determines that the priority is high, the WTRU can determine to perform measurements for WTRU validation purposes, despite the WTRU being configured to skip measurements. The WTRU can receive an indication of the priority for measurements and / or measurement reporting from the network (e.g., LMF, base station, or TRP).

[0320] For example, a WTRU can be configured with thresholds for location based measurements (e.g., inter-frequency cell / intra-frequency measurements). For example, if a location of a WTRU is within a threshold from a reference point (e.g., to save power in the WTRU battery) when the WTRU is in an inactive state, the WTRU can not perform inter-frequency cell or intra-frequency measurements. However, even if the location is valid and the WTRU is within the threshold from the reference point (or any rule / condition for skipping measurements is met), if the priority level associated with WTRU location validation is high (or higher than the priority level associated with skipping measurements) and one of the preconfigured rules for reporting measurements for location validation (e.g., the WTRU location is outside the threshold compared to a reference point, and / or the elapsed time compared to a reference time is greater than the threshold) requires the WTRU to perform measurements (e.g., to maintain validity of the WTRU location), the WTRU can determine to perform measurements (e.g., PRS measurements, inter-frequency cell / intra-frequency measurements) regardless of the state of the WTRU (e.g., regardless of whether the WTRU is in RRC CONNECTED, inactive, or idle mode).

[0321] In some examples, a WTRU can be configured by a network with priority levels for measurement reporting for location validation. According to the configured priority levels, a WTRU can determine that measurement reporting can be associated with a higher or lower priority level compared to other channels (e.g., PUSCH, PUCCH).

[0322] Conditions for transitioning to RRC CONNECTED mode for WTRU validation are described herein. In some examples, if at least one of the aforementioned conditions for performing WTRU validation is met while the WTRU is in an idle / inactive state, the WTRU can determine to transition to RRC CONNECTED. For example, if the WTRU is in an idle state and the WTRU determines that the elapsed time since the last time the location of the WTRU was validated is expired, the WTRU can determine to perform initial access so that the WTRU can report measurements made on PRS to the network while the WTRU is in RRC CONNECTED state.

[0323] In some examples, if at least one of the aforementioned conditions for performing WTRU validation is met, for example, and if the WTRU is in an inactive state, the WTRU can determine to transition to RRC CONNECTED mode (e.g., via performing initial access, sending a request to the network to transition to RRC CONNECTED mode). In some examples, the WTRU can determine to transition to RRC CONNECTED mode, for example, if the WTRU determines that the size of measurement reporting for WTRU location validation purposes is greater than a preconfigured threshold.

[0324] In some examples, a WTRU can determine at a validation occasion (e.g., broadcast by the network) that the WTRU can determine to perform an initial access so that the WTRU can report or so that the network can validate the WTRU location through the initial access procedure. For example, the WTRU can report its location information to the network via Msg3, Msg5, and / or the WTRU can identify its location information via a preamble, where each preamble can be associated with a zone / cell ID.

[0325] Solutions for network initiated periodic validation are described herein. In some examples, a WTRU can determine a validation occasion configured by the network. The WTRU can be semi-statically configured (e.g., via RRC, LPP, or other logically equivalent signaling) with a periodicity for the validation occasion and / or a start time of a first validation occasion. The WTRU can determine one or more actual validation occasions based on ephemeris of one or more satellites or a serving time frame (e.g., represented by parameter t-service) of a current serving cell.

[0326] Figure 7 is a diagram illustrating a configuration of a WTRU operating according to periodic validation occasions. In Figure 7 In the example shown, a WTRU can be configured to communicate with satellite #1 and satellite #2, each satellite configured to move along a different orbital path over time. The WTRU can be configured with periodic validation occasions between T1 and T2 and between T5 and T6. Meanwhile, the coverage of satellite #1 can be such that PRS can be received at T1, T3, T5, and T7, while the coverage of satellite #2 can be such that PRS can be received between T2 and T4 and between T6 and T8. The WTRU can determine, e.g., based on ephemeris information of satellites #1 and #2, that the two occasions between T1 and T2 and between T5 and T6 are invalid because the WTRU cannot make measurements of PRS transmitted from either satellite due to a coverage gap. The WTRU can not be able to transmit validation information (e.g., measurements, and / or WTRU location estimates derived through GNSS-based methods) or make measurements of PRS at that occasion. The WTRU can determine to skip the invalid validation occasions.

[0327] The WTRU can determine actual validation occasions based on one or more aspects. One aspect can be satellite ephemeris information. For example, in Figure 7 In the scenario shown, the WTRU can determine the timing of actual validation occasions when the WTRU is able to make measurements of received PRS and / or transmit SRS to configured TRP(s) (e.g., satellite #1 and / or satellite #2). For example, as Figure 7As shown, the WTRU may determine that the actual verification opportunity is between T3 and T4, K time slots after T3, when the WTRU is in the coverage area of ​​both satellite #1 and satellite #2. Another actual verification opportunity may be determined between T7 and T8, when the WTRU is in the coverage area of ​​satellite #2.

[0328] Another aspect of the WTRU's determination of the actual verification opportunity may be the configured / dynamic authorization of SRS transmission. For example, when the WTRU is configured with authorization (e.g., configured or dynamic) to transmit SRS to the configured TRP(s) (e.g., satellite), the WTRU may determine the actual verification opportunity a configured duration / time before the actual verification opportunity, if applicable.

[0329] In some examples, the WTRU may report one or more parameters related to the actual verification opportunities to the network. The parameters may include the period of the actual verification opportunities; the start / end time / duration of the actual verification opportunities; and / or the pattern of the actual verification opportunities. For example, there may be a duration during which the WTRU cannot see the configured satellites. In some examples, the actual verification may occur aperiodically. The WTRU may indicate the pattern of the actual verification opportunities via a bit sequence, where the number of bits in the sequence corresponds to the number of opportunities in the period.

[0330] Figure 8 FIG is a diagram showing the visible period of a satellite and the timing of the verification opportunity based on the period. Figure 8 As shown in the example of illustration 801 of FIG, a satellite 810 may be configured to move along an orbital path over time, arriving at positions 810a, 810b, 810c, 810d, 810e, and 810f at respective times T5 / T11, T6 / T12, T7 / T13, T8, T9, and T10. A WTRU 820 may be configured to measure the PRS from the satellite 810 and may be configured to have verification opportunities at T6, T8, T10, and T12. However, the satellite 810 may not be visible to the WTRU at T3, and more importantly in this example, may not be visible at T9 (e.g., having NLOS to the WTRU), so the WTRU 820 may determine to skip the verification opportunity at T10. Figure 8In the example shown, the configured validation occasions for the WTRU are periodic, and the occasions configured for a single period include the occasions at T6, T8, T10, and T12, which is due to the ephemeris of satellite 810. Thus, in the example shown, WTRU 820 can send a pattern represented by the bit sequence [1 1 0 1] to the network, where “1” and “0” indicate a validation occasion in which the WTRU can perform validation (e.g., make measurements on PRS) or the WTRU cannot perform validation, respectively. Since satellite 810 can move according to a predictable ephemeris, the network can use this pattern to determine the occasions that WTRU 820 skips.

[0331] In some examples, the WTRU can determine how frequently to report to the network that it skips a configured validation occasion. For example, the WTRU can report the density of actual validation occasions in the configured validation occasions. For example, in the example above, the WTRU can report a density of 50%, indicating that 1 out of 2 validation occasions are skipped. Figure 7 In the example shown (basically introduced and described in the paragraph above), the WTRU can indicate to the network a density of 50%, indicating that 1 out of 2 validation occasions are skipped. The WTRU can report a duration (e.g., in seconds, number of symbols / slots / frames) until the next actual validation occasion. The WTRU can receive an ACK / NACK from the network, where the ACK / NACK indicates approval / rejection of the periodicity of actual validation occasions reported by the WTRU. If the WTRU receives a rejection message (e.g., a message indicating that the network cannot accept the periodicity of actual validation occurrences), the WTRU can determine to perform initial access to establish a connection with the network.

[0332] In some examples, the WTRU can be configured by the network with information indicating a list of periodicities. Based on ephemeris information of one or more satellites and the location of the WTRU determined from GNSS (or GPS), the WTRU can determine a periodicity of actual validation occasions from the list of periodicities. The WTRU can report the determined periodicity to the network. For example, if the WTRU determines that more than one periodicity is applicable, the WTRU can determine to report the shortest / longest periodicity according to a preconfigured rule (e.g., the WTRU can send the report based on a rule hardcoded in the specification).

[0333] In some solutions, resources can be limited according to the amount of skipped occasions. In one such example, a WTRU can determine that the quality of service received by the WTRU from the network can be associated with the frequency with which the WTRU skips the configured validation occasions. For example, the WTRU can be configured by the network with a rule associated with the frequency of skipped occasions and the amount of resources that can be scheduled for the WTRU. For example, according to the rule, the WTRU can determine that if the WTRU skips 50% of its configured validation occasions, the WTRU can be configured or allocated with up to 5MHz of bandwidth for uplink transmissions (e.g., PUSCH transmissions). In some examples, the WTRU can determine according to the rule that if the WTRU would send a measurement report and / or a position determined according to the GNSS / GPS based method at all configured occasions (e.g., without skipping validation occasions), the WTRU can be configured by the network with up to 100MHz of bandwidth.

[0334] In some example embodiments, a WTRU can perform a NW initiated validation. In one or more steps of an example procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites) from the network. In one or more steps of the procedure, the WTRU can receive from the network configuration information for a validation period (e.g., indicating validation occasions to occur at configured periods) and a measurement duration (e.g., K time slots). In one or more steps of the procedure, if the WTRU cannot make measurements for RAT dependent positioning at least for the measurement duration before the configured validation occasion (e.g., if there are not enough satellites for a multi-RTT method), the WTRU can report measurements obtained via RAT dependent positioning methods and can report a position estimate based on GNSS methods at the next validation occasion. In such a case, the report can include a timestamp of when the measurements were made. In one or more steps of the procedure, the WTRU can report RAT dependent measurements, an estimated position derived using GNSS based methods at the actual validation occasion, and a timestamp of when the measurements were made.

[0335] In some examples, the WTRU can send an indication of an index associated with a validation occasion in which the WTRU can report measurements and / or a position estimate obtained via a GNSS-based method. In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, and / or information for a RAT-dependent positioning method) and validation occasions via one or more broadcast messages. In one or more steps of the procedure, the WTRU can determine its position based on GNSS-based measurements. Based on the validation occasions and the ephemeris information, the WTRU can report (e.g., by sending an indication of the validation occasion index) an occasion in which the WTRU can report a position estimate / measurement via GNSS-based and RAT-based positioning methods.

[0336] In some example procedures, the WTRU can indicate an offset with respect to a configured validation occasion in which the WTRU can report measurements and / or a position estimate obtained via a GNSS-based method. The WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, and / or information for a RAT-dependent positioning method) and validation occasions via one or more broadcast messages. The WTRU can determine its position based on GNSS-based measurements. Based on the validation occasions and the ephemeris information, the WTRU can suggest a preferred parameter for the validation occasion (e.g., an offset of N minutes).

[0337] In some example implementations, the WTRU can use more than one periodicity to perform a network-initiated validation. The WTRU can be given a list of periodicities for validation occasions from the network. Based on the WTRU’s position and based on ephemeris information, the WTRU can select a periodicity from the list in which the WTRU can send a measurement report. If there is more than one determined periodicity, the WTRU can select the shortest periodicity. In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites) from the network. The WTRU can receive a list of validation periodicities from the network. Based on the list of periodicities, ephemeris information, and the WTRU’s position determined via GNSS-based methods, the WTRU can determine a periodicity from the list in which the WTRU reports required measurements to the network. If the WTRU determines more than one periodicity from the list, the WTRU reports the shortest periodicity from the determined periodicities to the network. The WTRU can report the determined periodicity to the network. In some methods, at a preconfigured time (e.g., a start time of the validation) from the occasion in which the WTRU reports the determined periodicity, the WTRU can report required measurements (e.g., RAT-dependent measurements, a position estimated via GNSS-based methods, and / or one or more timestamps) to the network at the validation occasion.

[0338] In some example embodiments, a WTRU can be penalized for skipping validation occasions. For example, a network can request a WTRU to perform location validation at a certain periodicity. If the WTRU cannot comply with the request (e.g., due to NLOS with the necessary number of satellites), the WTRU can experience a degraded quality of service due to the compromised validation periodicity. If the WTRU cannot successfully complete location validation (e.g., at the requested periodicity), the WTRU can perform an initial access.

[0339] In one or more steps of the procedure, the WTRU can receive from the network assistance information (e.g., ephemeris information for one or more satellites), information indicating an association between a frequency of skipped validation occasions and a maximum bandwidth of an uplink channel (e.g., PUSCH) that the WTRU can request. The WTRU can receive configuration information for a validation periodicity (e.g., indicating that validation occasions occur at a configured periodicity). Based on the ephemeris information and a WTRU location determined by a GNSS-based method, the WTRU can determine actual validation occasions. Based on a proportion of skipped validation occasions (e.g., (a number of configured validation occasions - a number of actual occasions) divided by the number of configured validation occasions) and the received association configuration, the WTRU can determine a maximum bandwidth that the WTRU can request for uplink transmission. The WTRU can transmit an indication of the determined maximum bandwidth that it can request (e.g., using a MAC-CE, UCI, or any other logically equivalent message). If the WTRU cannot determine validation occasions, the WTRU determines to perform an initial access procedure (e.g., the WTRU performs a fallback behavior).

[0340] In some solutions, the WTRU can send GPS information and receive actual validation occasions. For example, the WTRU can determine to send a location estimate obtained via a GNSS / GPS-based method to the network according to an indication or configuration provided by the network. The WTRU can receive from the network information indicating actual validation occasions and / or a periodicity of SRS configuration based on the reported WTRU location. For example, the WTRU can receive an SRS configuration, where parameters (e.g., start / end time of SRS transmission, periodicity, repetition factor) can be aligned with configured actual validation occasions.

[0341] The WTRU can not report GNSS / GPS location information at actual validation occasions unless one or more conditions are met. One condition can be that the WTRU moves more than a preconfigured threshold (e.g., expressed in meters). Another condition can be that a validation period of GNSS / GPS-derived location information expires. Another condition can be that the WTRU receives from the network an indication to report WTRU location information based on GNSS / GPS.

[0342] In some example embodiments, a WTRU can perform a network-initiated validation using an initial position estimate based on GNSS. In one or more steps of the procedure, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites) from the network. The WTRU can determine a preparation duration based on a configuration or capability of the WTRU. The WTRU can determine or select satellites for which to perform measurements based on transmitted PRS. The WTRU can report position information derived via a GNSS-based method to the network WTRU. The WTRU can receive a first period of actual validation occasions from the network. At an actual validation occasion, the WTRU can report measurement results (e.g., RSRP, RSTD) based on PRS transmitted by the selected satellites and can report WTRU position information derived via a GNSS-based method if the WTRU moves a distance that exceeds a configured or preconfigured threshold. If the WTRU receives a second period based on the reported WTRU position estimate and associated with the actual validation occasion, the WTRU can replace the first period with the second period. The WTRU can determine a next actual occasion based on the second period and the preparation duration.

[0343] In some solutions, a WTRU can determine alignment of a validation occasion with a scheduled positioning time. For example, a WTRU position validation occasion can be associated with a RACH configuration. In some examples, a preamble selected by a WTRU can be associated with a particular occasion in which validation is performed. A mapping between preamble selection and validation occasion(s) can be provided, for example, by the network or indicated within system information. For example, a subset of preambles A-B can be associated with validation occasion X and a subset of preambles B-C can be associated with validation occasion Y.

[0344] In some examples, a RACH occasion selected by a WTRU can indicate which validation occasion should be used. A relationship between RACH configuration and validation occasion can be defined, for example, by a particular offset from a RACH occasion, a particular duration from a RACH occasion, and / or based on a validation occasion closest to a RACH occasion. In some examples, a WTRU can trigger a WTRU position validation (e.g., perform positioning measurements for RAT-dependent positioning method(s), determine a WTRU position from GNSS, and / or transmit a measurement report to a network) when any validation occasion overlaps with at least one configured set of scheduled positioning time (SLT) occasions. In the case where a duration of a validation occasion is greater than an SLT occasion during an overlap window between the occasions, the WTRU can limit the WTRU position validation to the duration of the validation occasion, for example, to possibly ensure service continuity.

[0345] In some examples, the WTRU can send WTRU location verification information (e.g., measurements for RAT-dependent positioning method(s), GNSS determined WTRU location) at SLT if one or more conditions are met. One condition can be that the SLT occurs between WTRU location verification occasions. One condition can be that the SLT occurs before the first verification occasion during a verification window / after the WTRU receives a request from the network to initiate WTRU location verification. One condition can be that the SLT occurs after the last verification occasion during a verification window / after the WTRU receives a request from the network to terminate WTRU location verification. One condition can be that the WTRU receives an indication / configuration from the network to perform WTRU location verification occasions at SLT.

[0346] In some examples, the WTRU can receive configuration information from the network (e.g., LMF, base station) related to SLT occasions (e.g., time at which the WTRU needs to report its location / measurement on PRS, periodicity of SLT occasions, content of WTRU reporting). In some examples, the WTRU can receive a request from the network for SLT occasions to report location information (e.g., measurements and / or WTRU’s location).

[0347] In some examples, the WTRU can determine to use a new verification occasion based on an event occurring a pre-configured time before / after the event, where the pre-configured time is expressed in a time unit (e.g., time slot, symbol, frame, second, hour). For example, the WTRU can determine that an event has occurred based on at least one of the following triggers. One trigger can be the occurrence of SLT, where the WTRU can trigger WTRU location verification a pre-configured time window before the next verification / SLT occasion. Another trigger can be a request from the network to perform location verification, where the WTRU can trigger WTRU location verification after the WTRU receives the request from the network. Another trigger can be the reception of an RRC_Release message (e.g., a request from the network to the WTRU to transition to RRC_INACTIVE state), where the WTRU can trigger WTRU location verification after the WTRU receives the request from the network. Another trigger can be a scheduled call from the WTRU, where the WTRU can trigger WTRU location verification a pre-configured time before the next scheduled call. For example, the WTRU can be a sensor that periodically reports measurement data (e.g., temperature and / or air pressure) to the network.

[0348] In some examples, the WTRU may trigger early location verification when an event / condition associated with discontinuous coverage is determined during any of the next verification and / or SLT opportunities. In such a case, when a discontinuous coverage event is expected to overlap with the next verification / SLT opportunity, the WTRU may initiate WTRU location verification at a preconfigured time (e.g., N time slots) before the next verification / SLT opportunity. The WTRU may skip WTRU location verification in associated opportunities that overlap with the discontinuous coverage event. For example, when the WTRU determines that there is an overlap between a discontinuous coverage event and a subsequent verification / SLT opportunity, the WTRU may send an indication to the network in any earlier verification / SLT opportunity.

[0349] In some examples, the WTRU may determine the validity of a new verification opportunity based on at least one of the following conditions. One condition may be that a new verification opportunity is valid if the WTRU can send a report to the network, where the report contains measurements made by the WTRU on PRS transmitted from the configured TRPs (e.g., satellites). One condition may be that a new verification opportunity is valid if the WTRU can measure PRS from a minimum number of TRPs (e.g., satellites) for the configured positioning method. Another condition may be that the new verification opportunity may be valid if the new verification opportunity occurs at a preconfigured time (e.g., K time slots) after the verification opportunity, such that the WTRU does not need to perform location verification during a short period of time. In some examples, if performing verification is feasible, the WTRU may determine to perform WTRU location verification at a preconfigured time before the next verification / SLT opportunity.

[0350] In some examples, if the WTRU determines that the new verification occasion is invalid, the WTRU may perform one or more actions. One action may be that the WTRU may indicate that the location information / measurements returned in the SLT are based on the determined verification occasion (e.g., by including a timestamp of the measurements, which may be one of the determined periodic occasions). Another action may be that the WTRU may not return location information / measurements in the SLT.

[0351] Figure 9 is a diagram showing determination of a new verification timing.

[0352] exist Figure 9 In the example shown, the WTRU may be configured to receive and measure PRS from two satellites (satellite #1 and satellite #2). The WTRU may determine the periodicity of the verification opportunity based at least on the coverage of each satellite. Figure 9Satellite #1 can provide coverage in the WTRU's area at times T1, T3, T5, and T7. Satellite #2 can provide coverage in the WTRU area between T2 and T4 and between T6 and T8. The WTRU can be configured with a validation occasion at T4 and T8 and configured with a SLT occasion between T6 and T7. Based on the SLT occasion, the WTRU can determine to create a new validation occasion a preconfigured time (e.g., N slots) before the SLT occasion. It should be noted that in Figure 9 the example shown, the SLT occasion occurs during a period where the WTRU has coverage only under Satellite #2. However, in other examples not shown in Figure 9 , the timing of the SLT occasion can not be limited to scenarios with partial coverage, but can be determined in scenarios where the WTRU has no satellite coverage (e.g., when the WTRU receives no PRS from either Satellite #1 and Satellite #2). Figure 9 In other examples not shown in , the timing of the SLT occasion can not be limited to scenarios with partial coverage, but can be determined in scenarios where the WTRU has full satellite coverage (e.g., when the WTRU receives PRS from both Satellite #1 and Satellite #2).

[0353] Since the WTRU can measure PRS from both Satellite #1 and Satellite #2 at the new validation occasion, it can determine that the new validation occasion is valid as shown in Figure 9 between T3 and T4 in . Thus, the WTRU can determine to perform location validation (e.g., measure PRS from Satellite #1 and from Satellite #2) at the new validation occasion.

[0354] Figure 10 is a diagram showing rejection of a new validation occasion. In Figure 10 the example shown, the WTRU can again be configured to receive and measure PRS from two satellites (Satellite #1 and Satellite #2). Satellite #1 can provide coverage in the WTRU's area at times T1, T3, T5, and T7. Satellite #2 can provide coverage in the WTRU area between T2-T4 and T6-T8. The WTRU can be configured with a validation occasion at T4 and T8 and configured with a SLT occasion between T6 and T7. Between T2 and T3, the WTRU can have coverage only from Satellite #2. The WTRU can determine to create a new validation occasion a preconfigured time (e.g., M slots) before the SLT occasion. However, in Figure 10 the example shown, since the WTRU can only measure PRS received from Satellite #2 at the new validation occasion, the WTRU can determine that the new validation occasion is invalid. Thus, the WTRU can determine to perform validation at validation occasion #1 (e.g., at time T4 shown in Figure 10 .

[0355] Methods for WTRU-initiated periodic location validation are described herein. In some examples, a WTRU can determine a validation occasion based on ephemeris of one or more satellites configured. For example, a WTRU can determine a start time and a periodicity of a validation occasion based on ephemeris information (e.g., how many satellites are visible to the WTRU, and / or a visibility period) and a RAT-dependent positioning method (e.g., single / multi-satellite based positioning).

[0356] Figure 11 is a diagram illustrating an example of a location validation determination made by a WTRU. In Figure 11 In the example shown, a WTRU can be configured to receive and measure PRS from two satellites (Satellite #1 and Satellite #2). Satellite #1 can provide coverage in the area of the WTRU at times T1, T3, T5, and T7. Satellite #2 can provide coverage in the area of the WTRU from T2-T4 and from T6-T8. Based on ephemeris information and the coverage status of Satellites #1 and #2, the WTRU can determine that there are validation occasions between T3 and T4 and between T7 and T8, at which time the WTRU can be located within the coverage area of both Satellites #1 and #2. The WTRU can evaluate the duration between the two validation occasions and can also determine a validation occasion periodicity based on the duration.

[0357] In some examples, if the WTRU determines more than one periodicity available for a validation occasion, the WTRU can determine the periodicity that it should use in a process with one or more steps. In one or more steps of the process, the WTRU can determine a list of periodicities for validation occasions, sorted by the duration of the periodicities. In one or more steps of the process, the WTRU can report to the network the longest periodicity as the validation periodicity and the corresponding start time. In one or more steps of the process, if the WTRU does not receive a confirmation message from the network, the WTRU can select the second longest periodicity and the corresponding start time from the list of candidates. The WTRU can report the periodicity to the network as the validation periodicity.

[0358] In some examples, based on the location of the WTRU and ephemeris information of one or more satellites, the WTRU can determine more than one periodicity available for a validation occasion.

[0359] Figure 12 is a diagram illustrating an example of a WTRU determining and evaluating more than one possible periodicity for a validation occasion. In Figure 12In the example shown, the WTRU can be configured to receive and measure PRS from at least one satellite. The satellite can provide coverage in the area of the WTRU at times T1, T3, T5, T7, T9, and T11. The WTRU can evaluate the duration of time between the initial time (T1) that the WTRU is in coverage of the satellite and each subsequent time (T3, T5, T7, T9, and T11) that the WTRU is again in coverage of the satellite. Thus, in Figure 12 In the example shown, the WTRU can determine at least five different possible periods for the validation occasion, with the shortest period being Figure 12 shown as period 1, and periods 2 through 5 being multiples of period 1. Each period can be calculated by the equation M*T, where M is an integer and T is the time interval represented by period 1. Figure 12 In the example shown, the time interval represented by period 1 is 1 hour.

[0360] The WTRU can be configured with rules (e.g., thresholds) regarding how to determine the period for WTRU location validation. In some examples, the WTRU can determine the period for the validation occasion based on one or more parameters.

[0361] One parameter can be the relative location with respect to the center of the cell (e.g., NTN cell). In some examples, if the WTRU is located closer to the edge of the cell, the WTRU can need to perform WTRU location validation more frequently. For example, the WTRU can be preconfigured with ranges of relative distances from the center. Based on the determined WTRU location (e.g., a location determined by a GNSS-based method), the WTRU can determine the range in which the WTRU is located. The WTRU can also be configured with rules associating each range with a required (e.g., minimum / maximum) period. If the WTRU determines more than one period, the WTRU can select the period based on the rules and / or the location of the WTRU. For example, if the WTRU determines more than one period, the WTRU can determine to select a shorter period (e.g., provide more frequent validation occasions) if the WTRU is located further from the center of the cell. The WTRU can select a longer period (e.g., less frequent validation occasions) if the WTRU is located closer to the center of the cell.

[0362] Figure 13 is a graph showing an example of the relationship between the minimum period required for validation and the distance from the center of the NTN cell. In Figure 13 In the example shown, satellite 1310 can provide cellular network coverage within coverage area 1301. Coverage area 1301 can encompass cell 1320 with cell center 1325. As Figure 13 shown, the coverage range within the cell can be designated as exemplary distances of 100 km, 600 km, and 1000 km from the cell center 1325. However, inFigure 13 In other examples not shown, the reference point can not be limited to the cell center 1325. The reference point can be determined by the network and indicated to the WTRU. Each range can be associated with a required minimum period with respect to the cell center. If a WTRU operating within the cell 1320 determines that it is located in range 3 (between 600 km and 1000 km from the cell center), the WTRU can need to perform WTRU location verification at least every 2 hours. For example, based on the configured association rule between distance ranges from the cell center and minimum periods shown in Figure 13 In another example, based on the configured association rule between distance ranges from the cell center and minimum periods shown in Figure 13 In another example, based on the configured association rule between distance ranges from the cell center and minimum periods shown in

[0363] Another parameter for determining the period of location verification can be a priority associated with the longest / shortest period. For example, the WTRU can be configured with a priority level or rule that is hard-coded in the specification of the WTRU and that indicates whether the WTRU should report the longest / shortest period if the WTRU determines more than one period. If the WTRU determines that the period reported to the network is not accepted by the network, the WTRU can determine to report a period that is longer / shorter than the reported period.

[0364] Another parameter for determining the period of location verification can be a service requirement. For example, the WTRU can be configured with a service requirement (e.g., specifying how long the specified service can tolerate missing WTRU location verification, a minimum period, and / or a maximum period). Based on the service requirement, the WTRU can determine a period that satisfies the requirement.

[0365] Another parameter for determining periodicity of location verification can be whether the WTRU is in RRC CONNECTED state or RRC INACTIVE / IDLE state. If the WTRU is in inactive mode, the WTRU can need to conserve battery power, and the WTRU can not be able to perform WTRU verification as frequently as the WTRU operating in RRC CONNECTED state. The state of the WTRU can determine the periodicity that the WTRU is able to maintain. The WTRU can determine the periodicity based on the capability of the WTRU or based on configuration information from the network (e.g., in some configurations, the minimum periodicity that the WTRU can report when in RRC CONNECTED or RRC INACTIVE can be 2 hours or 10 hours, respectively).

[0366] Another parameter for determining periodicity of location verification can be the periodicity of SRS transmission. In some examples, the WTRU can be configured with a grant (e.g., configured / dynamic grant) for SRS transmission. The WTRU can determine the periodicity of the verification occasion based on the SRS transmission. For example, the WTRU can determine a verification occasion within a preconfigured time (e.g., N slots) from the SRS transmission. In some examples, the WTRU can be configured with more than one set of SRS configurations. The WTRU can determine the periodicity of selecting SRS transmission based on ephemeris information (e.g., based on a periodicity aligned with ephemeris of a satellite).

[0367] In some examples, the WTRU can be configured with more than one set of SRS configurations. The WTRU can determine the periodicity of SRS transmission based on the determined periodicity of the actual verification occasion.

[0368] The WTRU can report the determined verification parameter(s) to the network. The WTRU can receive an approval / confirmation message from the network for the determined and reported verification parameter(s). In one example, the WTRU can receive one or more messages from the network (e.g., via RRC, LPP, MAC-CE, DCI, or other logically equivalent messages) after the WTRU sends the determined verification parameter to the network.

[0369] One message can be a confirmation message approving the verification parameter determined by the WTRU. Another message can be a message rejecting the verification parameter determined by the WTRU. Another message can be a message denying a requested service (e.g., call, data transmission / reception request, emergency call) from the WTRU. Another message can be a message including a verification parameter (e.g., periodicity). In some examples, the WTRU can receive a verification parameter from the network, which can be determined by the network based on the verification parameter determined and / or reported by the WTRU.

[0370] Another message can include an information request from the network. In some examples, the WTRU can receive a request from the network requesting additional information (e.g., RSRP of PRS from a particular satellite and / or WTRU ID). Another message can include a QoS indication. In some examples, the WTRU can receive a QoS indication (e.g., change in positioning requirements, reporting requirements, data service rate, change in maximum / minimum configurable PRS parameters such as bandwidth, change in time for scheduling calls / SLTs) based on the validation parameters determined and / or reported by the WTRU.

[0371] In some examples, the determined periodicity of actual validation can be based on the positioning method configured by the WTRU. For example, based on the positioning method, the number of TRPs (e.g., satellites) can be different. Based on the ephemeris information and the number of satellites required for the positioning method, the WTRU can determine the periodicity of actual validation occasions that the WTRU can report measurements to the network.

[0372] In an example implementation, the WTRU can perform WTRU initiated validation. The WTRU can determine a periodicity for validation. The WTRU can send an indication of the determined periodicity to the network and can determine whether it is acceptable by the network. If not, the WTRU can keep the periodicity information and send the periodicity information in order of duration (e.g., longest to shortest). If none are acceptable, the WTRU can determine to perform initial access.

[0373] At one or more steps of the procedure, the WTRU can receive assistance information from the network (e.g., ephemeris information for one or more satellites, and / or information for a RAT-dependent positioning method). The WTRU can determine its position based on GNSS measurements. Based on the ephemeris of one or more satellites, the configured RAT-dependent positioning method (e.g., DL-TDOA), and the determined position, the WTRU can determine a validation parameter (e.g., a period). If the WTRU determines more than one period, the WTRU can determine or select the longest period. The WTRU can report the determined validation parameter (e.g., period) to the network. If the WTRU receives an ACK from the network, the WTRU can perform the RAT-dependent positioning before the validation occasion (e.g., a preconfigured time from when the WTRU receives the ACK). The WTRU can send the GNSS-based position estimate and measurements performed via the RAT-dependent positioning method to the network at the validation occasion. If the WTRU does not receive an ACK from the network (e.g., within a preconfigured time from when the WTRU sent the determined validation parameter), and if the WTRU determined more than one period, the WTRU can select the next longest period (e.g., the second longest period) and report it to the network. If the WTRU does not receive an ACK from the network, the WTRU can repeat the procedure until the WTRU does not have any remaining candidate periods. Otherwise, the WTRU can determine to perform an initial access procedure (i.e., the WTRU can perform a fallback behavior).

[0374] In some embodiments, the WTRU can perform a WTRU-initiated validation using a required period obtained from the network. At one or more steps of the procedure, the WTRU can receive assistance information from the network (e.g., ephemeris information for one or more satellites, and / or information for a RAT-dependent positioning method). The WTRU can determine its position based on GNSS measurements. Based on the ephemeris information of one or more satellites, the configured RAT-dependent positioning method (e.g., DL-TDOA), and the determined position, the WTRU can determine a period. If the WTRU determines more than one suitable validation parameter value (e.g., period), the WTRU can determine the longest period. The WTRU can report the determined period to the network. If the WTRU receives an ACK from the network, the WTRU can perform the RAT-dependent positioning before the validation occasion (e.g., a preconfigured time from when the WTRU receives the ACK). The WTRU can send the GNSS-based position estimate and measurements from the RAT-dependent positioning method to the network at the validation occasion.

[0375] If the WTRU does not receive an ACK from the network (e.g., within a preconfigured time from when the WTRU sent the determined validation parameters) and if the WTRU determines more than one period, the WTRU can select the next longest period (e.g., the second longest period) and report it to the network. The WTRU can repeat the procedure until the WTRU does not have any candidate periods. Otherwise, the WTRU can determine to perform an initial access procedure (i.e., the WTRU can perform a fallback behavior).

[0376] A request for SRS configuration is described herein. In some examples, a WTRU can determine to send a request to the network for SRS configuration aligned with actual validation occasions. For example, the WTRU can determine that the period of one or more actual validation occasions is 6 hours. The WTRU can determine to send a request to the network for SRS configuration that specifies a SRS transmission period of 6 hours.

[0377] A method for optical validation is described herein. In some examples, a WTRU can determine a period of actual validation occasions and report the period, location information determined from GNSS and / or from satellite ID / TRP ID that the WTRU can measure. The WTRU can also indicate in the report SRS configuration(s) for SRS transmission depending on the configured positioning method. Based on the reported information, the network is able to validate the WTRU location as the ID of visible satellites and the period of actual validation occasions can implicitly indicate the WTRU location. In one or more steps of the procedure, the WTRU can receive from the network assistance information (e.g., ephemeris information for one or more satellites, and / or information for RAT dependent positioning methods) and information indicating a minimum number of satellites N. The WTRU can determine its location based on GNSS measurements. Based on the ephemeris information of one or more satellites, the WTRU can determine actual validation occasions, corresponding satellite IDs, and the period of validation occasions, the number of satellites can be greater than or equal to N. The WTRU can report to the network the period of actual validation occasions, satellite IDs, and location information determined via GNSS based method.

[0378] In some solutions, a WTRU can replace a positioning method or use more than one positioning method. For example, a WTRU can determine to use multiple positioning methods. A WTRU can determine that there is more than one set of actual validation opportunities. For a set of actual validation opportunities, a WTRU can determine to perform a single-satellite based positioning method (e.g., RTT based positioning method). For another set of validation opportunities, a WTRU can determine to perform a multi-satellite based positioning method (e.g., DL-TDOA). A WTRU can determine to employ more than one positioning method at an actual validation opportunity based on one or more conditions. One condition can be based on ephemeris information that determines that a WTRU can perform a single-satellite based positioning method (e.g., RTT based positioning method) at a set of actual opportunities, and a WTRU can perform a multi-satellite based positioning method (e.g., DL-TDOA). If a WTRU determines that a set of actual validation opportunities exists, a WTRU can determine to report to a network parameters for each set (e.g., periodicity of actual validation opportunities, associated positioning method). Another condition can be based on one or more configurations indicated by a network. For example, a WTRU can be configured with more than one set of validation opportunities, and a WTRU can determine to use a positioning method associated with each set of opportunities.

[0379] Figure 14 is a diagram illustrating an example of a set of validation opportunities. As shown in Figure 14 , a WTRU can be configured to receive and measure PRS from two satellites (Satellite #1 and Satellite #2). Satellite #1 can provide coverage in a WTRU’s area at times T1, T3, T5, and T7. Satellite #2 can provide coverage in a WTRU’s area from T2 to T4 and from T6 to T8. A WTRU can determine that there are two sets of validation opportunities (e.g., based on ephemeris and / or configuration information from a subsequent network): a first set including validation opportunity #1-1 located between T3 and T4 and validation opportunity #1-2 located between T7 and T8, and a second set including validation opportunity #2-1 located between T1 and T2 and validation opportunity #2-2 located between T5 and T6.

[0380] In Figure 14In the illustrated example, the WTRU can also be configured with more than one positioning method. Alternatively, or additionally, based on the ephemeris, the WTRU can determine to use more than one positioning method. The WTRU determines two sets of actual validation occasions based on the ephemeris. For validation occasions #1-1 and #1-2, assuming the WTRU is in the coverage area of both satellites at these times, the WTRU can determine that the WTRU can make measurements from both satellites #1 and #2. Thus, the WTRU can determine to use a positioning method that requires measurements from more than one TRP / satellite (e.g., DL-AoD). For validation occasions #2-1 and #2-2, the WTRU determines that the WTRU can only make measurements of PRS from one TRP / satellite at a time, because the WTRU is only in the coverage area of satellite #1 during validation occasions #2-1 and #2-2, thus, the WTRU can determine to use a positioning method that requires measurements from one TRP / satellite over a configured interval (e.g., the WTRU can use a RTT-based positioning method).

[0381] In some examples, the WTRU can report to the network which positioning method(s) the WTRU is capable of performing based on the ephemeris of the satellite. Based on the positioning methods the WTRU is capable of using, the WTRU can receive configuration information (e.g., periodicity information) related to actual validation occasions. If applicable, the WTRU can receive information for more than one set of validation occasions, where each set can be associated with a positioning method.

[0382] Validation based on a mobility event can be further described as follows. If the WTRU determines that it has moved further than a configured threshold, the WTRU can determine to trigger WTRU location validation. The location validation can occur within a time limit from the mobility event. Otherwise, the WTRU can need to perform initial access to establish a connection with the network.

[0383] Figure 15 is a flow diagram illustrating an example procedure for mobility triggered validation. As shown at 1510, the WTRU can receive assistance information (e.g., ephemeris information for one or more satellites, configuration information for RAT-dependent positioning methods), a first threshold, and a second threshold (e.g., expressed in meters and hours, respectively) from a network (e.g., LMF, base station, or TRP). As shown at 1520, the WTRU can detect that it has moved a distance beyond the first threshold (a detected mobility event) relative to a reference point (e.g., a reported location at a previous reporting occasion, a cell center). The WTRU can determine one or more validation occasions based on the received ephemeris information, as shown at 1530. If the determined validation occasion is within the second threshold from the time of the detected mobility event, the WTRU can transmit validation information to the network at the determined validation occasion, as shown at 1540.

[0384] The validation information can include: a location determined, e.g., by a RAT dependent positioning method, a location estimate obtained from GNSS, and / or a measurement report (e.g., RSTD, RSRP for DL-TDOA) when the information becomes available. If the determined validation occasion is after a preconfigured time from the time of the detected mobility event, the WTRU can perform an initial access to establish a connection with the network.

[0385] Network initiated validation with penalty for skipped occasions can be further described as follows. The network can want to perform WTRU location validation with a certain periodicity. If the WTRU cannot comply with the request (e.g., due to lack of satellites seen by the WTRU), the WTRU can determine a quality of service associated with the compromised periodicity. If the WTRU cannot determine a validation occasion, the WTRU can perform an initial access.

[0386] Figure 16 is a flow diagram illustrating an example procedure for network initiated validation with penalty for skipped occasions. As shown at 1610, the WTRU can receive assistance information (e.g., ephemeris of satellites) from the network and information indicating an association between a frequency of skipped validation occasions and a maximum bandwidth of an uplink channel (e.g., PUSCH) that the WTRU can request.

[0387] As shown at 1620, the WTRU can receive configuration information for a validation periodicity (e.g., providing validation occasions occurring at a configured periodicity). Based on the ephemeris information and a WTRU location determined using a GNSS based method, the WTRU can determine actual validation occasions, as shown at 1630. Based on a proportion of skipped validation occasions (e.g., (number of configured validation occasions - number of actual occasions) to number of configured validation occasions) and the received association configuration, the WTRU can determine a maximum bandwidth that the WTRU can request for uplink transmission, as shown at 1640.

[0388] As shown at 1650, the WTRU can transmit an indication of the determined maximum bandwidth that it can request. The transmitted indication can be sent using a MAC-CE, UCI, or another logically equivalent message, for example. If the WTRU cannot determine a validation occasion, the WTRU can determine to perform an initial access procedure (i.e., perform a fallback behavior).

[0389] Methods for WTRU initiated validation are further described herein. The WTRU can determine a periodicity for validation. The WTRU can send the periodicity to the network and determine whether the periodicity is acceptable by the network. If not, the WTRU can keep sending the periodicity in order of duration (e.g., longest to shortest). If none are acceptable, the WTRU can determine to perform an initial access.

[0390] Figure 17 FIG. 8 is a flow diagram illustrating an example procedure for WTRU initiated location verification. The WTRU can receive assistance information from the network (e.g., ephemeris of satellites, RAT dependent positioning method). The WTRU can determine its location based on GNSS measurements. Based on the ephemeris of satellites, the configured RAT dependent positioning method (e.g., DL-TDOA), and the determined location, the WTRU can determine a periodicity. If the WTRU determines more than one suitable verification parameter value (e.g., periodicity), the WTRU can determine the longest periodicity. The WTRU can report the determined periodicity to the network.

[0391] If the WTRU receives an ACK from the network, the WTRU can perform RAT dependent positioning prior to the verification occasion (e.g., a preconfigured time from the time the ACK is received from the WTRU). The WTRU can send the GNSS based location estimate and measurements from the RAT dependent positioning method to the network at the verification occasion.

[0392] If the WTRU does not receive an ACK from the network (e.g., within a preconfigured time from the time the determined verification parameter is sent from the WTRU), and if the WTRU determines more than one periodicity, the WTRU selects the next longest periodicity (e.g., the second longest periodicity) and reports it to the network. The WTRU can repeat the procedure until the WTRU does not have any candidate periodicity. Otherwise, the WTRU can determine to perform an initial access procedure (fallback behavior).

[0393] Although features and elements are described above in particular combinations, one of ordinary skill in the art will appreciate that each feature or element can be used alone or in combination with others dependent upon the circumstances. The methods described herein can be implemented in a computer program, software, or firmware incorporated in a computer- readable medium for execution by a computer or processor. Examples of computer-readable media include electronic signals (optical, electrical or electromagnetic) that are transmittable through a wired or wireless connection. Examples of computer-readable media include, but are not limited to, a read only memory (ROM), random access memory (RAM), register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs). A processor in association with software can be used to implement a radio frequency transceiver for use in a WTRU, UE, terminal, base station, RNC, or any host computer.

Claims

1. A method for mobility-triggered location verification performed by a wireless transmit / receive unit (WTRU), the method comprising: receiving assistance information from a network, the assistance information comprising one or more of: ephemeris information associated with at least one satellite, an indication of a range threshold, and an indication of a duration; detecting a mobility event based on an amount of movement of the WTRU exceeding the distance threshold; On condition that a location verification opportunity is expected after a detected mobility event but before expiration of said duration from the detected mobility event: Transmitting location verification information to the network at the location verification opportunity.

2. The method according to claim 1, comprising: After a detected mobility event and conditional upon a location verification opportunity being expected after expiration of said duration from the detected mobility event: An initial access procedure is attempted to establish a connection to the network.

3. The method of claim 1 , wherein the location verification information comprises an estimated location of the WTRU determined using a Global Navigation Satellite System (GNSS) based method.

4. The method of claim 1 , wherein the location verification information comprises an estimated location of the WTRU determined using a radio access technology (RAT)-dependent positioning method.

5. The method of claim 1 , wherein the mobility event is determined based on an amount the WTRU has moved from a location at which the WTRU previously performed location verification.

6. The method of claim 1, comprising transmitting a sounding reference signal to one or more of the at least one satellite to support a radio access technology (RAT)-dependent positioning method.

7. The method of claim 1, wherein the network is a terrestrial network comprising at least one base station.

8. The method of claim 1 , wherein the assistance information is received after the WTRU enters a coverage area of ​​a non-terrestrial network (NTN) associated with the at least one satellite.

9. The method of claim 1, wherein the assistance information is received in one of system information, a random access channel (RACH) message, a medium access control (MAC) control element (CE), or a radio resource control message (RRC).

10. A wireless transmit / receive unit (WTRU) configured to perform mobility-triggered location verification, the WTRU comprising: processor; as well as transceiver; The processor and the transceiver are configured to receive assistance information from a network, the assistance information comprising one or more of: ephemeris information associated with at least one satellite, an indication of a range threshold, and an indication of a duration; The processor and the transceiver are configured to detect a mobility event based on an amount of movement of the WTRU exceeding the distance threshold; The processor and the transceiver are configured to, conditional upon a location verification opportunity being expected after a detected mobility event but before expiration of the duration from the detected mobility event: Transmitting location verification information to the network at the location verification opportunity.

11. The WTRU of claim 10 , wherein the processor and the transceiver are configured to, upon a condition that a location verification opportunity is expected after a detected mobility event and after expiration of the duration from the detected mobility event: An initial access procedure is attempted to establish a connection to the network.

12. The WTRU of claim 10, wherein the location verification information comprises an estimated location of the WTRU determined using a Global Navigation Satellite System (GNSS) based method.

13. The WTRU of claim 10, wherein the location verification information comprises an estimated location of the WTRU determined using a radio access technology (RAT)-dependent positioning method.

14. The WTRU of claim 10, wherein the mobility event is determined based on an amount the WTRU has moved from a location at which the WTRU previously performed location verification.

15. The WTRU of claim 10, comprising transmitting a sounding reference signal to one or more of the at least one satellite to support a radio access technology (RAT) dependent positioning method.

16. The WTRU of claim 10, wherein the network is a terrestrial network comprising at least one base station.

17. The WTRU of claim 10, wherein the assistance information is received after the WTRU enters a coverage area of ​​a non-terrestrial network (NTN) associated with the at least one satellite.

18. The WTRU of claim 10, wherein the assistance information is received in one of system information, a random access channel (RACH) message, a medium access control (MAC) control element (CE), or a radio resource control message (RRC).

Images