Method for relay-assisted network-based operation by out-of-coverage target WTRU

Abstract

A wireless transmit / receive unit (WTRU) includes a processor configured to determine that an anchor WTRU supports a relay function for sidelink (SL) positioning. The WTRU may be outside of a network coverage area, and the anchor WTRU may be inside of the network coverage area. The processor may establish an indirect non-access stratum (NAS) connection with the network via the anchor WTRU based on the anchor WTRU supporting a relay function, determine the network support SL location via the indirect NAS connection, and perform a network-based operation via the relay function of the anchor WTRU based on the determination of the network support SL location.

Description

[0001] Cross-reference to related applications This application claims the benefit of U.S. Provisional Application No. 63 / 517,967, filed August 7, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] In 3GPP, a target WTRU can determine whether to select WTRU-only or network-based sidelink (SL) positioning. The target WTRU can determine to select WTRU-only operation if, for example, neither the target WTRU nor the SL-anchored WTRU is served by a network (e.g., outside coverage), or the serving network (e.g., LMF capability) does not support SL positioning. The target WTRU can determine to select network-based operation if, for example, neither the target WTRU nor the SL-anchored WTRU is served by a network (e.g., within coverage), or the serving network (e.g., LMF capability) supports SL positioning.

[0003] When an out-of-coverage (OoC) target WTRU initiates a location request (e.g., SL-MO-LR, 5GC-MO-LR), the OoC target WTRU can discover one or more anchored WTRUs to obtain location-related measurements. Upon detecting (e.g., at least one in-coverage (IC) anchored WTRU, the OoC target WTRU can determine to perform an SL location request for network-based operations. However, if, for example, the IC anchored WTRU does not support ProSe L2 WTRU-to-network relay functionality, or if the serving network (e.g., LMF) does not support SL location (e.g., older versions of LMF), the OoC target WTRU cannot perform network-based SL location via the IC anchored WTRU. Summary of the Invention

[0004] A wireless transmit / receive unit (WTRU) may include a processor. The processor may be configured to determine that the anchored WTRU supports relay functionality for side-link (SL) positioning. The WTRU may be located, for example, outside a network coverage area. The anchored WTRU may be located, for example, within a network coverage area. The processor may be configured to establish an indirect non-access stratum (NAS) connection to the network via the anchored WTRU based on the anchored WTRU supporting relay functionality. The processor may be configured to determine that the network supports SL positioning via the indirect NAS connection. The processor may be configured to perform network-based operations via the relay functionality of the anchored WTRU based on the determination that the network supports SL positioning.

[0005] Anchored WTRUs can determine their support for relay functionality, for example, based on the Proximity Service (ProSe) Layer 2 (L2) relay discovery process.

[0006] The anchored WTRU can determine that it supports relay functionality for SL positioning. For example, the processor can be configured to send a request message to the anchored WTRU (e.g., a request to support relay functionality for SL positioning). In some examples, the processor can establish a connection with the anchored WTRU. The processor can be configured to receive a response message from the anchored WTRU (e.g., establishing a PC5-RRC connection with the anchored WTRU based on an indication that the anchored WTRU supports relay functionality for SL positioning). The response message may, for example, indicate that the anchored WTRU supports relay functionality for SL positioning. The WTRU can be configured to establish a proximity-based Serving Communications 5 Radio Resource Control (PC5-RRC) connection with the anchored WTRU based on the indication that the anchored WTRU supports relay functionality for SL positioning.

[0007] The request message may include, for example, a query for the capability to support relay functions for SL positioning, sent via a proximity-based Serving Communications 5 Radio Resource Control (PC5-RRC) connection.

[0008] The processor can be configured to perform SL-PRS measurements, for example, based on a side link positioning reference signal (SL-PRS) received from the anchored WTRU.

[0009] The processor can be configured to transmit SL-PRS measurement results to the network, for example, via the anchored WTRU, to estimate the location of the WTRU.

[0010] The WTRU can determine if the network supports SL positioning, where the processor can be configured to send a query message to the network via the anchored WTRU to determine whether the Location Management Function (LMF) in the network supports SL positioning. The processor can be configured to receive a response message from the LMF via the anchored WTRU. The response message may, for example, indicate that the network supports SL positioning.

[0011] The processor can be configured to select the anchored WTRU based on, for example, one or more SL measurements that are above a threshold.

[0012] Thresholds may include, for example, the sidelink reference signal received power (SL-RSRP) value.

[0013] The processor can be configured to detect anchored WTRUs in the vicinity of WTRUs.

[0014] The processor can be configured to determine WTRU-only operations. The processor can be configured to perform a server WTRU discovery process. The server WTRU discovery process can be based on determining that relay functionality is not enabled on any of one or more In-Coverage (IC) anchored WTRUs.

[0015] The processor can be configured to determine WTRU-only operations. The processor can be configured to perform a server WTRU discovery procedure. The server WTRU discovery procedure can be based on the determination that the network does not support SL location.

[0016] A WTRU can be configured to perform a method including one or more of the following steps: The method may include determining that the anchored WTRU supports relay functionality for side-link (SL) positioning. The WTRU may be located outside a network coverage area, for example. The anchored WTRU may be located within a network coverage area, for example. The method may include establishing an indirect non-access stratum (NAS) connection to the network via the anchored WTRU based on the anchored WTRU supporting relay functionality. The method may include determining that the network supports SL positioning via the indirect NAS connection. The method may include performing network-based operations via the relay functionality of the anchored WTRU based on determining that the network supports SL positioning.

[0017] This method may include anchoring WTRUs to determine their support for relay functionality, for example, based on the Proximity Service (ProSe) Layer 2 (L2) relay discovery process.

[0018] The method may include determining, for example, that the anchored WTRU supports relay functionality for SL positioning by sending a request message to the anchored WTRU. The method may include receiving a response message from the anchored WTRU. The response message may, for example, indicate that the anchored WTRU supports relay functionality for SL positioning. The method may also include the WTRU establishing a PC5-RRC connection with the anchored WTRU based on the indication that the anchored WTRU supports relay functionality for SL positioning.

[0019] The request message may include, for example, a query for the capability to support relay functions for SL positioning, sent via a proximity-based Serving Communications 5 Radio Resource Control (PC5-RRC) connection.

[0020] The method may include, for example, performing SL-PRS measurements based on a side link positioning reference signal (SL-PRS) received from the anchored WTRU.

[0021] This method may include, for example, transmitting SL-PRS measurement results to the network via the anchored WTRU to estimate the location of the WTRU.

[0022] This method may include the WTRU determining whether the network supports SL positioning by sending a query message to the network via the anchored WTRU to determine whether the Location Management Function (LMF) in the network supports SL positioning. The method may also include receiving a response message from the LMF via the anchored WTRU. The response message may, for example, indicate that the network supports SL positioning.

[0023] This method may include selecting the anchored WTRU based on, for example, one or more SL measurements above a threshold.

[0024] Thresholds may include, for example, the sidelink reference signal received power (SL-RSRP) value.

[0025] This method may include detecting anchored WTRUs in the vicinity of WTRUs.

[0026] This method may include a WTRU-only operation to determine WTRUs. This method may include performing a server WTRU discovery procedure. The server WTRU discovery procedure may be based on determining that relay functionality is not enabled on any of one or more In-Coverage (IC) anchored WTRUs.

[0027] This method may include a WTRU-only operation to determine the WTRU. This method may include performing a server WTRU discovery procedure. The server WTRU discovery procedure may be based on determining that the network does not support SL positioning. Attached Figure Description

[0028] Figure 1A This is a system diagram illustrating an example communication system in which one or more of the disclosed embodiments can be implemented.

[0029] Figure 1B The illustration shows that, according to the embodiment, it is possible to... Figure 1A The diagram shows a system diagram of an example wireless transmit / receive unit (WTRU) used in a communication system.

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

[0031] Figure 1D The illustration shows that, according to the embodiment, it is possible to... Figure 1A The system diagram shows a further example RAN and a further example CN used within the communication system shown.

[0032] Figure 2 This is a system diagram illustrating an example of SL localization for an OoC target WTRU.

[0033] Figure 3 This is a system diagram illustrating an example of network-based operations assisted by an OoC target WTRU.

[0034] Figure 4 This is a flowchart illustrating an example of a relay-assisted network-based process performed by an OoC target WTRU.

[0035] Figure 5 This is a system diagram illustrating an example of network-based operations assisted by a relay-assisted WTRU.

[0036] Figure 6 This is a flowchart illustrating an example of a relay-assisted network-based process performed by an anchored WTRU.

[0037] Figure 7 This is a system diagram illustrating an example of service continuity for an OoC target WTRU.

[0038] Figure 8 This is a flowchart illustrating an example of a service continuity process performed by an OoC target WTRU.

[0039] Specific implementation method Figure 1A This diagram illustrates an example communication system 100 in which one or more of the disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content (such as voice, data, video, messaging, broadcasting, etc.) to multiple wireless users. The communication system 100 enables multiple wireless users to access such content by sharing system resources (including wireless bandwidth). For example, the communication system 100 may employ one or more channel access methods, such as Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Orthogonal FDMA (OFDMA), Single Carrier FDMA (SC-FDMA), Zero-Tail Unique Word DFT Extended OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Bank Multicarrier (FBMC), etc.

[0040] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110, and other networks 112. Although it will be appreciated, 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. For example, WTRUs 102a, 102b, 102c, and 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to transmit and / or receive wireless signals and may include user equipment (UE), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular phones, personal digital assistants (PDAs), smartphones, laptops, netbooks, personal computers, wireless sensors, hotspots or Mi-Fi devices, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain scenarios), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Any of WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as WTRUs. Furthermore, any descriptions herein relating to UEs may equally apply to WTRUs (or vice versa). For example, the WTRU can be configured to execute any procedure or program described herein as being executed by the UE (or vice versa).

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

[0042] Base station 114a may be part of RAN 104 / 113, which may also include other base stations and / or network elements (not shown), such as base station controllers (BSCs), radio network controllers (RNCs), relay nodes, etc. Base station 114a and / or base station 114b may be configured to transmit and / or receive radio signals on one or more carrier frequencies, which may be referred to as cells (not shown). These frequencies may be in licensed spectrum, unlicensed spectrum, or a combination of licensed and unlicensed spectrum. A cell may provide coverage for a specific geographic area for radio services, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In one embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology, and multiple transceivers may be used for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

[0043] Base stations 114a and 114b can communicate with one or more of WTRUs 102a, 102b, 102c, and 102d via air interface 116, which can be any suitable wireless communication link (e.g., radio frequency (RF), microwave, millimeter wave, infrared (IR), ultraviolet (UV), visible light, etc.). Air interface 116 can be established using any suitable radio access technology (RAT).

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

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

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

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

[0048] In other embodiments, base station 114a and WTRUs 102a, 102b, 102c can implement the following radio technologies, such as IEEE 802.11 (i.e., WiFi), IEEE 802.16 (i.e., WiMAX), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rate GSM Evolution (EDGE), GSMEDGE (GERAN), etc.

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

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

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

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

[0053] Figure 1B This is a system diagram illustrating example WTRU 102. (Example:) Figure 1B As shown, WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keyboard 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and / or other peripheral devices 138, etc. It will be appreciated that WTRU 102 may include any sub-combination of the above-described elements while remaining consistent with the embodiments.

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

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

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

[0057] Transceiver 120 can be configured to modulate signals to be transmitted by transmitting / receiving element 122 and demodulate signals received by transmitting / receiving element 122. As noted above, WTRU 102 can have multi-mode capability. Thus, for example, transceiver 120 may include multiple transceivers for enabling WTRU 102 to communicate, for example, via multiple RATs (such as NR and IEEE 802.11).

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

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

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

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

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

[0063] Figure 1C The diagram illustrates a system diagram of RAN 104 and CN 106 according to an embodiment. As noted above, RAN 104 employs E-UTRA radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 104 can also communicate with CN 106.

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

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

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

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

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

[0069] SGW 164 can be connected to PGW 166, which can provide WTRU 102a, 102b, 102c with access to a packet-switched network (such as Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices.

[0070] CN 106 facilitates communication with other networks. For example, CN 106 can provide WTRUs 102a, 102b, and 102c with access to a circuit-switched network (such as PSTN 108) to facilitate communication between WTRUs 102a, 102b, and 102c and conventional terrestrial line communication equipment. For instance, CN 106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN 106 and PSTN 108. Additionally, CN 106 can provide WTRUs 102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0071] Despite WTRU in Figures 1A to 1D While described as a wireless terminal, it is envisioned that, in some representative embodiments, such a terminal may use (e.g., temporarily or permanently) a wired communication interface with a communication network.

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

[0073] In Infrastructure Basic Services Set (BSS) mode, a WLAN may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic into and / or out of the BSS. Traffic originating outside the BSS destined for a STA can be reached via the AP and delivered to the STA. Traffic from a STA to a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be sent via the AP, for example, where a source STA can send traffic to the AP, and the AP can deliver the traffic to the destination STA. Traffic between STAs within the BSS can be considered and / or referred to as peer-to-peer traffic. Peer-to-peer traffic can be sent between source and destination STAs (e.g., directly between them) using a direct link setup (DLS). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). A WLAN using the Standalone BSS (IBSS) mode can exist without an access point (AP), and STAs within the IBSS or using the IBSS (e.g., all STAs) can communicate directly with each other. The IBSS communication mode may sometimes be referred to as the "ad-hoc" communication mode in this document.

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

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

[0076] Very High Throughput (VHT) STAs can support channels with widths of 20MHz, 40MHz, 80MHz, and / or 160MHz. 40MHz and / or 80MHz channels can be formed by combining consecutive 20MHz channels. A 160MHz channel can be formed by combining eight consecutive 20MHz channels or by combining two non-consecutive 80MHz channels (which can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is passed through a segment resolver that divides the data into two streams. Inverse Fast Fourier Transform (IFFT) processing and time-domain processing can be performed separately on each stream. The streams can be mapped onto two 80MHz channels, and the data can be transmitted by the STA performing the transmission. At the receiver of the receiving STA, the above operations for the 80+80 configuration can be reversed, and the combined data can be sent to the Media Access Control (MAC).

[0077] Operating modes below 1 GHz are supported by 802.11af and 802.11ah. The channel operating bandwidth and carrier used in 802.11af and 802.11ah are reduced compared to those used in 802.11n and 802.11ac. 802.11af supports 5 MHz, 10 MHz, and 20 MHz bandwidths in the TV 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 instrument-type control / machine-type communications, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support for (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a lifespan exceeding a threshold (e.g., to maintain a very long battery life).

[0078] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include a channel that can be designated as the primary channel. The primary channel can have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel can be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the 802.11ah example, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel can be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, 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 because an STA (which only supports the 1MHz operating mode) is transmitting to the AP, the entire available band may be considered busy, even if most of the band is still idle and available.

[0079] In the United States, the available frequency band for 802.11ah is from 902MHz to 928MHz. In South Korea, the available frequency band is from 917.5MHz to 923.5MHz. In Japan, the available frequency band is from 916.5MHz to 927.5MHz. Depending on the country code, the total available bandwidth for 802.11ah ranges from 6MHz to 26MHz.

[0080] Figure 1D The diagram illustrates a system diagram of RAN 113 and CN 115 according to one embodiment. As indicated above, RAN 113 may employ NR radio technology to communicate with WTRUs 102a, 102b, and 102c via air interface 116. RAN 113 may also communicate with CN 115.

[0081] RAN 113 may include gNBs 180a, 180b, and 180c, although it will be understood that RAN 113 may include any number of gNBs while remaining consistent with the embodiments. gNBs 180a, 180b, and 180c may each include one or more transceivers for communicating with WTRUs 102a, 102b, and 102c via air interface 116. In one embodiment, gNBs 180a, 180b, and 180c may implement MIMO technology. For example, gNBs 180a and 180b may utilize beamforming to transmit signals to and / or receive signals from gNBs 180a, 180b, and 180c. Therefore, gNB 180a may, for example, use multiple antennas to transmit radio signals to and / or receive radio signals from WTRU 102a. In one embodiment, gNBs 180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB 180a can transmit multiple component carriers to 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 one embodiment, gNBs 180a, 180b, and 180c can implement Cooperative Multipoint (CoMP) technology. For example, WTRU 102a can receive cooperative transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0082] WTRUs 102a, 102b, and 102c can use transmissions associated with scalable digitization. For example, OFDM symbol spacing and / or OFDM subcarrier spacing can vary depending on different transmissions, different cells, and / or different portions of the radio transmission spectrum. WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c using subframes of various or scalable lengths or transmission time intervals (TTIs) (e.g., containing different numbers of OFDM symbols and / or absolute times of varying durations).

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

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

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

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

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

[0088] UPF 184a and 184b can connect to one or more of gNBs 180a, 180b, and 180c in RAN 113 via the N3 interface. These gNBs can provide WTRU 102a, 102b, and 102c with access to packet-switched networks (such as the Internet 110) to facilitate communication between WTRU 102a, 102b, 102c and IP-enabled devices. UPF 184a and 184b can perform other functions such as routing and forwarding packets, enforcing user plane policies, supporting multi-homed PDU sessions, handling user plane QoS, buffering downlink packets, and providing mobility anchoring.

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

[0090] Given Figures 1A to 1D as well as Figures 1A to 1D The corresponding description may be performed by one or more emulation devices (not shown) to perform one or more of the functions described in the text with respect to one or more of the following: WTRU 102a to 102d, base stations 114a to 114b, eNode-B 160a to 160c, MME 162, SGW 164, PGW 166, gNB 180a to 180c, AMF 182a to 182b, UPF 184a to 184b, SMF 183a to 183b, DN 185a to 185b, and / or any other devices described herein. An emulation device may be one or more devices configured to emulate one or more or all of the functions described herein. For example, an emulation device may be used to test other devices and / or simulate network and / or WTRU functions.

[0091] Simulation devices can be designed to perform one or more tests on other devices in a laboratory environment and / or a carrier network environment. For example, one or more simulation devices can perform one or more functions while being fully or partially implemented and / or deployed as part of a wired and / or wireless communication network to test other devices within the communication network. One or more simulation devices can perform one or more functions while being temporarily implemented / deployed as part of a wired and / or wireless communication network. Simulation devices can be directly coupled to another device for testing purposes and / or can use over-the-air wireless communication to perform tests.

[0092] One or more emulation devices can perform one or more functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, emulation devices can be used to test test scenarios in a laboratory and / or non-deployed (e.g., testing) wired and / or wireless communication networks to enable testing of one or more components. One or more emulation devices can be test devices. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may include one or more antennas) can be used by the emulation devices to transmit and / or receive data.

[0093] NR positioning provides a means of determining the geographic location and / or speed of a WTRU based on measurements of radio signals. The WTRU's location information (e.g., location) can be calculated by the WTRU, or relevant positioning measurements can be reported to the network (e.g., LMF). To support the WTRU's positioning information, the LTE Positioning Protocol (LPP) has been researched and standardized by 3GPP. LPP uses a point-to-point protocol between the network (e.g., LMF) and the target WTRU. The target WTRU can obtain positioning-related measurements via one or more positioning reference sources (e.g., TRPs) through the Uu interface (e.g., uplink or downlink).

[0094] Sidelink (SL) positioning protocols can be implemented. NR PC5-based positioning supported by the Sidelink Positioning Protocol (SLPP) has been studied in 3GPP. SLPP-based services provide distance measurement and procedures between one or more WTRUs. SLPP uses a point-to-point protocol between WTRUs (e.g., target WTRU, anchor WTRU, server WTRU). To obtain positioning information from a WTRU, the target WTRU performs location-related measurements using one or more SL positioning reference sources (e.g., anchor WTRU).

[0095] SL positioning operations can be performed using network-based operations or WTRU-only operations. In network-based operations, the Location Management Function (LMF) participates in SL positioning and performs supporting functions. The LMF supports many functions used for SL positioning, such as determining the SL positioning method, distributing ancillary data, and calculating the location of the target WTRU. If the target WTRU is out of coverage or the serving network does not support SL positioning, the SL Positioning Server WTRU can participate in SL positioning in place of the LMF to support SL positioning-related functions. For example, the SL Positioning Server WTRU can provide support functions such as determining the SL positioning method, distributing ancillary data, and calculating the location of the target WTRU.

[0096] NR SL relay methods can be implemented. SL relay can be introduced to support ProSe L2 U2N relay functionality. The relay function provides connectivity to the network from a WTRU (e.g., a relay UE) to another WTRU (e.g., a remote WTRU). To support ProSeL2 U2N-based relay, relay is performed above the RLC sublayer at both the WTRU and the network. WTRUs can exchange data in any direction. A single PC5 unicast link can be established between a relay WTRU and a remote WTRU. ProSe L2 U2N relay can be applied to partial coverage scenarios where at least one WTRU is within coverage to relay to the network. SL positioning operations also support partial coverage scenarios. In this scenario, one WTRU (e.g., an anchor WTRU) can be within coverage, while another WTRU (e.g., a target WTRU) can be outside coverage.

[0097] Indirect NAS connections can be implemented. When the target WTRU is out of coverage (OoC), it may not be able to directly establish a NAS connection with the serving network (e.g., LMF) because the OoC target WTRU may not be able to reach / connect to the serving network. Therefore, when the OoC target WTRU connects to an IC anchored WTRU (e.g., supporting relay functionality), the OoC target WTRU can establish an indirect NAS connection to the serving network. For example, after establishing a PC5 unicast connection with the IC anchored WTRU, the OoC target WTRU can send an initial NAS message (e.g., a registration request) to the IC anchored WTRU. The IC anchored WTRU can then deliver the received NAS message to the serving network. Similarly, the IC anchored WTRU can receive a response message (e.g., a registration acceptance) from the serving network and deliver the received response message to the OoC target WTRU to establish an indirect NAS connection. In this disclosure, an indirect NAS connection can be defined as a NAS connection established via a relay WTRU. The relay WTRU can deliver all messages (e.g., SLPP messages, SLPP control signaling, SL measurement results) between the OoC target WTRU and the serving network.

[0098] The NR discovery method can be implemented. SL discovery can detect one or more other nearby WTRUs via the PC5 interface. When the target WTRU (or the network triggers the SL location service), the target WTRU can detect one or more nearby WTRUs and perform location-related measurements on the detected one or more WTRUs. Two types of discovery processes use discovery signals (or messages): Mode A and Mode B.

[0099] In Mode A discovery, the notifying WTRU sends an SL location notification message. For example, the anchoring WTRU can transmit or broadcast a notification message (e.g., "I am the anchoring WTRU") to nearby WTRUs. In Mode B discovery, the discovering WTRU (e.g., one that wants to discover) can send an SL location solicitation message. For example, the solicitation message can include a request to discover the anchoring WTRU. Upon receiving the solicitation message, the anchoring WTRU can respond to the discovering WTRU with an SL location response message. For example, the response message can include identification information (e.g., "Here, I am the anchoring UE"). In both Mode A and Mode B, the location discovery message can indicate the role of the WTRU (e.g., the target WTRU, the anchoring WTRU).

[0100] Figure 2 This is a system diagram illustrating an example of SL positioning for an OoC target WTRU. When the OoC target WTRU is connected to the LMF via an IC anchored WTRU, the OoC target WTRU can perform network-based SL positioning. When the OoC target WTRU may be unable to connect (or the LMF does not support SL positioning), the OoC target WTRU can perform WTRU-based SL positioning. The LMF may be involved when the target WTRU and anchored WTRU are within network coverage and the serving network supports SL positioning. For example, the LMF can provide at least one of the following functions: The LMF can provide network-based positioning (e.g., triggering SL positioning). The LMF can provide SL positioning capabilities (e.g., SL-OTDOA, SL-RTT) and assistance for data distribution and SL-PRS configuration to another WTRU. The LMF can configure SL-PRS configuration and / or measurement configuration (e.g., network-based LMF, WTRU-based LMF) and provide a subset or all of the pre-configured SL-PRS configuration and / or measurement configuration to another WTRU. LMF can determine the location of the target UE based on the SL-PRS results reported by the target WTRU.

[0101] When an Out-of-Care (OoC) target WTRU initiates a location request (e.g., SL-MO-LR, 5GC-MO-LR), the OoC target WTRU can discover one or more anchored WTRUs to obtain its location using SL-PRS measurements. If none of the anchored WTRUs are served by the network (e.g., all anchored WTRUs are out of coverage) or the serving network does not support SL location, the OoC target WTRU can determine to perform WTRU-only operation for the location request. The target WTRU can then perform SL location server WTRU discovery. If a server WTRU is discovered, the target WTRU can establish a PC5 connection with the detected server WTRU. The server WTRU can then provide SL location services.

[0102] The OoC target WTRU can determine to perform WTRU-only operations and execute the server WTRU discovery process. The server WTRU discovery process can be performed based on determining that relay functionality is not enabled on any of one or more anchored WTRUs within coverage, or based on determining that the network does not support SL positioning.

[0103] Examples of server WTRUs can be (for example, at least) one of the following: A WTRU with LMF capabilities (e.g., providing SL-PRS configuration to another WTRU, providing measurement configuration to another WTRU, assisting in data distribution). A WTRU pre-configured with SL-PRS and / or measurement configurations by an LMF (e.g., a network-based LMF, a WTRU-based LMF), which provides a subset or all of the pre-configured SL-PRS and / or measurement configurations to another WTRU. A WTRU acting as an anchor WTRU (e.g., a timing reference, a reference for RSTD calculation) can be an example of a server WTRU.

[0104] Two positioning modes support SL positioning (e.g., WTRU-assisted and WTRU-based). In WTRU-assisted mode, the target WTRU can perform SL-PRS measurements with the assistance of the serving network and can transmit the SL-PRS measurements to the serving network (e.g., LMF), where the SL-PRS measurements are used to calculate (or estimate) the location of the target WTRU. In WTRU-based mode, the target WTRU performs SL-PRS measurements and uses the SL-PRS measurements to calculate (e.g., or estimate) its location.

[0105] SLPP sessions can be used between the target WTRU and the LMF (e.g., or the server WTRU) in the serving network to obtain location-related measurements or location estimates, or to transfer auxiliary data. Each SLPP session includes one or more SLPP transactions, where each LPP transaction performs a single operation (e.g., SL positioning capability exchange, SL auxiliary data transfer, or SL location information transfer).

[0106] As an example, an SL-PRS configuration may include at least one of the following parameters: number of symbols, transmission power, number of SL-PRS resources included in the SL-PRS resource set, SL-PRS silence mode (e.g., the silence mode may be expressed via a bitmap), period, type of SL-PRS (e.g., periodic, semi-persistent, or aperiodic), time slot offset for periodic SL-PRS transmission, vertical shift of the SL-PRS mode in the frequency domain, time slot during repetition, repetition factor, RE (resource element) offset, comb pattern, comb size, spatial relationship, QCL information for SL-PRS (e.g., QCL target, QCL source), number of PRUs, number of TRPs, absolute radio frequency channel number (ARFCN), subcarrier spacing, expected RSTD, uncertainty in expected RSTD, starting physical resource block (PRB), bandwidth, BWP ID, number of frequency layers, start / end time of PRS transmission, SL-PRS on / off indicator, TRP ID, SL-PRS ID, cell ID, global cell ID, PRU ID, and / or applicable time window. WTRU can apply SL-PRS configuration provided that the current time is within the applicable time window.

[0107] Channel measurements can be (pre)configured and include one or more of the following channel condition parameters: SL-PRSRSRP; SL-PRS SINR; SL-PRS CQI; number of detected multipaths; SL-PRS RSRPP (RSRP per path); LOS / NLOS indicator; Doppler shift; Doppler spread; average delay; and / or delay spread.

[0108] NR positioning methods can include DL-based positioning methods, UL-based positioning methods, and methods based on both UL and DL.

[0109] In DL-based positioning methods, DL-PRS is sent from multiple TRPs to the WTRU. The WTRU can observe and measure downlink signals from the TRPs. For WTRU-based methods, the WTRU can calculate its position, while for WTRU-assisted methods, the WTRU can return the downlink measurements to the network. For angle-based methods, the WTRU can report the AoA and RSRP of the downlink signals from the TRPs. For timing-based methods, the WTRU can report the RSTD. All these methods require timing synchronization between TRPs. Positioning calculation errors mainly stem from synchronization errors and multipath propagation.

[0110] In the UL-based positioning method, the WTRU and UE send a UL-PRS (e.g., a positioning SRS) configured by the RRC to the TRP. The network can then calculate the WTRU's location based on the cooperation of all TRPs that received the UL-PRS from the WTRU.

[0111] In the UL-DL based method, the WTRU measures the Rx-Tx time difference between the received DL-PRS and the transmitted UL-PRS. The Rx-Tx time difference and RSRP are reported to the network. The network can then coordinate the TRP to calculate the WTRU's location.

[0112] It enables network-based operations with relay assistance from the OoC target WTRU.

[0113] Figure 3 This is a system diagram illustrating an example of network-based operations assisted by an OoC target WTRU. Figure 3 The steps of a relay-assisted network-based operation performed by an OoC target WTRU are illustrated. For example, when the OoC target WTRU detects at least an IC-anchored WTRU that supports ProSe L2 relay WTRU functionality and the serving network supports SL positioning, the OoC target WTRU determines to perform a relay-assisted network-based operation.

[0114] A WTRU (e.g., an OoC target WTRU) can detect one or more WTRUs in the vicinity (e.g., anchored WTRU1, anchored WTRU2). After detecting (at least) an IC anchored WTRU, the OoC target WTRU can decide to check the relay functionality of the detected IC anchored WTRU. If it is determined that the IC anchored WTRU supports relay functionality, the OoC target WTRU can establish an indirect NAS connection via the IC anchored WTRU. In another example, the OoC target WTRU can determine to perform WTRU-only operation.

[0115] The OoC target WTRU can determine whether the serving network supports SL positioning. If the serving network supports SL positioning, the OoC target WTRU can determine to perform relay-assisted network-based operations with the candidate IC anchored WTRU. In another example, the OoC target WTRU can determine to perform WTRU-only operations.

[0116] The OoC target WTRU can perform SL-PRS measurements on one or more anchored WTRUs (e.g., IC anchored WTRU, OoC anchored WTRU). The OoC target WTRU can report the SL-PRS-based measurement results to the serving network via the IC anchored WTRU to estimate the location of the target WTRU.

[0117] An example SL discovery procedure for SL localization can be implemented. The OoC target WTRU can receive SL localization service requests (e.g., SL-MO-LR, 5GC-MO-LR) triggered by the SLPP layer of the target WTRU. The SL localization service request is a request to measure the relative (or absolute) position of the OoC target WTRU. Based on this request, the OoC target WTRU can perform position measurement by receiving one or more SL-PRS signals.

[0118] Initially, the OoC target WTRU can perform the SL discovery process, and the OoC target WTRU can discover and select one or more anchor WTRUs that enable the transmission of SL-PRS signals to the OoC target WTRU. After performing SL-PRS measurements using the selected anchor WTRUs, the OoC target WTRU can report the measurement results to the network (e.g., in the case of network-based operation) or the server WTRU (e.g., in the case of WTRU-only operation) to estimate and calculate the location of the OoC target WTRU.

[0119] To discover one or more nearby WTRUs (e.g., anchored WTRUs), the OoC target WTRU can send solicitation messages based on Mode B discovery (e.g., periodically / event-based). When transmitting the solicitation message, the OoC target WTRU may include indications (e.g., conditions) or roles (e.g., anchored UEs) in the transmitted solicitation message. For example, the indication may include a request to respond only if one or more anchored WTRUs have IC coverage, and a request to respond with information about the current coverage status (e.g., OoC or IC) of each anchored WTRU.

[0120] Upon receiving a solicitation message with this indication, the IC anchored WTRU may send a response message to the OoC target WTRU. Otherwise, the OoC anchored WTRU may not send a response message to the OoC target WTRU. The anchored WTRU may send a response message to the OoC target WTRU regarding the current coverage status (IC or OoC). For example, if the anchored WTRU is within coverage, it may determine that cell information is included. After receiving a response to the solicitation message (from one or more anchored WTRUs), the OoC target WTRU may consider one or more anchored WTRUs as one or more candidate WTRUs. Criteria for candidate WTRUs may include, for example, transmitting a response message during discovery and establishing a PC5 unicast connection (if possible).

[0121] An example that enables L2 trunk functionality support is determined. Among the candidate IC anchored WTRUs, one needs to be selected. The OoC target WTRU establishes a PC5 unicast connection with the selected IC anchored WTRU. For this selection, the OoC target WTRU checks whether each candidate IC anchored WTRU supports trunk functionality (e.g., ProSe L2 U2N).

[0122] If the (re)selected IC anchored WTRU does not support relay functionality, the OoC target WTRU may attempt to (re)select another candidate IC anchored WTRU sequentially from one or more candidate anchored WTRUs. If none of the candidate IC anchored WTRUs support relay functionality, the OoC target WTRU determines to perform WTRU-only operation (e.g., a mechanism to fall back to WTRU-only operation). To perform WTRU-only operation, the OoC target WTRU initiates a discovery process targeting neighboring server WTRUs. For example, the target WTRU may send messages indicating its location and the range where neighboring server WTRUs should be located (e.g., the target WTRU attempts to discover server WTRUs within 10 meters of its location).

[0123] If one or more candidate IC-anchored WTRUs are found to support relay functionality, the next step is to consider the SL measurement results from those candidate WTRUs. For this comparison, the OoC target WTRU is (pre-)configured (e.g., or configured by the network) with thresholds for SL measurement results (e.g., SD-RSRP, SD-RSSI). The OoC target WTRU can measure the SL measurement results from the discovery signal (or message) transmitted by the anchored WTRU during the SL discovery process. The OoC target WTRU can select an IC-anchored WTRU whose SL measurement result value is higher than the configured threshold (e.g., RSRP of the SL discovery signal from the anchored UE). However, even if there are more than one candidate IC-anchored WTRU with an SL measurement result higher than the configured threshold, the OoC target WTRU can select an IC-anchored WTRU with the highest SL measurement result value (e.g., the highest reported RSRP corresponding to the received SL discovery signal). Once an IC-anchored WTRU is selected, the OoC target WTRU can establish an indirect NAS connection with the serving network via that IC-anchored WTRU (e.g., operating as a relay WTRU).

[0124] OoC target WTRU can use one or more procedures to determine candidate IC anchored WTRU support for relay functions, including ProSe relay discovery procedures, relay functions via the PC5 ProSe layer, and WTRU capabilities via the proximity-based service communication 5 radio resource control (PC5-RRC) layer.

[0125] To check relay functionality, a ProSe L2 relay discovery process can be triggered by the ProSe layer of the OoC target WTRU. Based on the triggered relay discovery process (e.g., Mode B), the OoC target WTRU can send a ProSe L2 relay solicitation message (e.g., relay service code, indicator providing ProSe L2 relay, WTRU role) to the IC anchored WTRU. Upon receiving the solicitation message associated with relay discovery, the IC anchored WTRU can respond to the OoC target WTRU if it supports relay functionality and can operate as a relay WTRU. This approach is advantageous because the OoC target WTRU can determine whether the IC anchored WTRU supports relay functionality without establishing a PC5 unicast connection between the OoC target WTRU and the IC anchored WTRU (or before establishing such a connection).

[0126] To check trunk functionality, the OoC target WTRU can send a direct communication request to the IC anchored WTRU, including trunk-related parameters such as the trunk service code and an indicator providing ProSe L2 trunking. If the IC anchored WTRU supports trunk functionality and can operate as a ProSe L2 trunk WTRU, it can reply with a direct communication accept message to the OoC target WTRU. The OoC WTRU can send the direct communication request with some trunk parameters during capability exchange signaling via the PC5 unicast connection process. Alternatively, the OoC WTRU can send the direct communication request with some trunk parameters after / before the capability exchange signaling.

[0127] If the (re)selected IC anchored WTRU does not support ProSe L2 U2N trunking, the OoC target WTRU can (re)select another candidate IC anchored WTRU. When no candidate IC anchored WTRU supports L2 ProSe L2 U2N trunking, the OoC target WTRU can determine to perform WTRU-only operation. To perform WTRU-only operation, the OoC target WTRU can initiate a discovery process targeting the server WTRU.

[0128] After the PC5 unicast connection is established, the OoC target WTRU can establish an additional PC5-RRC connection on top of the PC5 unicast connection to exchange one or more RRC messages (e.g., RRC reconfiguration, SL measurement report). Based on the established PC5-RRC connection, the OoC target WTRU can send a WTRU capability query message to receive WTRU capabilities from the IC anchored WTRU. The OoC target WTRU can receive WTRU capability information sidelink messages from the IC anchored WTRU. When the OoC target WTRU receives capability information related to relay parameters (e.g., relayUE-Operation-L2) within the WTRU capability information sidelink message (e.g., indicating whether the IC anchored WTRU supports ProSe L2 U2N relay operation), the OoC target WTRU can determine whether the IC anchored WTRU supports relay functionality. Furthermore, the OoC target WTRU can also configure a relay indication (e.g., 1 bit) to the IC anchored WTRU during the SL RRC reconfiguration process. When the OoC target WTRU receives a relay indication from the IC anchored WTRU, the target WTRU can determine whether the IC anchored WTRU supports the relay function.

[0129] This provides an example of network-based operation that can be implemented with relay assistance. Once at least one IC-anchored WTRU is (re)selected and that IC-anchored WTRU supports ProSe L2 U2N relay functionality, the OoC target WTRU can establish an indirect NAS connection via the relay WTRU. For example, the target WTRU can send a registration request message to establish a NAS connection.

[0130] After establishing an indirect NAS connection, the OoC target WTRU can send a query message to the serving network to check if the LMF in the serving network supports SL positioning. The OoC target WTRU can send a query message to the serving network regarding SL positioning support (e.g., LMF version / release, supported SL positioning features / capabilities, supported SL releases). The LMF can send a response message with information about SL positioning. Upon receiving the response message from the serving network, the OoC target WTRU can determine whether the serving network supports SL positioning. The OoC target WTRU can determine to perform a WTRU-only operation on the triggered SL positioning service (e.g., a mechanism to fall back to WTRU-only operation), for example, because the serving network may not support SL positioning. To perform a WTRU-only operation, the OoC target WTRU can initiate a server WTRU discovery process, and the OoC target WTRU can release the NAS connection.

[0131] If the serving network supports SL positioning, the OoC target WTRU can determine to perform relay-assisted network-based operations. The OoC target WTRU can measure one or more SL-PRS transmissions from the IC-anchored WTRU. After performing the SL-PRS measurement, if WTRU-assisted positioning is configured, the OoC target WTRU can report the SL-PRS measurement results to the serving network via the IC-anchored WTRU. Based on the measurement results, the serving network (e.g., LMF) can estimate the location of the target WTRU. In another example, the OoC target WTRU can report the estimated location of the WTRU to the serving network via the IC-anchored WTRU.

[0132] Figure 4 This is a flowchart illustrating an example of a relay-assisted network-based process 400 performed by an OoC target WTRU.

[0133] In step 402, the target WTRU receives an SL positioning request from the SLPP layer.

[0134] In step 404, the target WTRU performs SL location discovery.

[0135] In step 406, it is determined whether the target WTRU has detected at least one IC-anchored WTRU. If no IC-anchored WTRU is detected, then in step 418, the target WTRU is determined to operate as a WTRU-only WTRU and performs discovery of the server WTRU, and process 400 ends.

[0136] If at least one IC-anchored WTRU is detected in step 406, then in step 408, it is determined whether a relay function is detected on the detected at least one IC-anchored WTRU. If no relay function is detected on at least one IC-anchored WTRU, then in step 418, the target WTRU is determined to operate as a WTRU only and performs discovery of the server WTRU, and process 400 ends.

[0137] If a relay function is detected in step 408, then in step 410, it is determined whether the serving network supports SL positioning. If it is detected that the serving network does not support SL positioning, then in step 418, the target WTRU is determined to operate as a WTRU only, and discovery of the server WTRU is performed, and process 400 ends.

[0138] If it is determined in step 410 that the serving network supports SL positioning, then in step 412, the target WTRU determines to perform relay-assisted network-based operations in the PC scenario.

[0139] In step 414, the target WTRU performs an SL-PRS measurement.

[0140] Finally, in step 416, the target WTRU reports the SL measurement results to the service network via the IC-anchored WTRU.

[0141] It enables network-based operations with relay assistance from anchored WTRUs.

[0142] Figure 5 This is a system diagram illustrating an example of network-based relay-assisted operation performed by an anchored WTRU. For example, when the anchored WTRU is within coverage and the serving network supports SL positioning, the IC-anchored WTRU can determine to perform network-based relay-assisted operation. The IC-anchored WTRU can transmit a discovery signal with relay information.

[0143] A WTRU (e.g., an anchored WTRU) can receive SL location solicitation messages from a WTRU (e.g., an OoC target WTRU). When the anchored WTRU is within coverage, the IC anchored WTRU can check whether the serving network (e.g., LMF) supports SL location. If the serving network supports SL location, the candidate IC anchored WTRU can determine to perform network-based operations with relay assistance. The IC anchored WTRU can respond to (or announce) an SL location discovery message, which includes an L2 relay indication. The L2 relay indication may include one or more of the following information: for example, a relay service code, the capability of supporting relay WTRUs. The IC anchored WTRU can establish an indirect NAS connection via the OoC target WTRU. The IC anchored WTRU can transmit SL-PRS to the OoC target WTRU. The IC anchored WTRU can relay SL-PRS measurements from the OoC target WTRU to the serving network.

[0144] This enables the identification of examples of network-based operations assisted by relays. In Mode B discovery, the anchored WTRU can receive solicitation messages from the target WTRU (e.g., periodically / event-based). Once a solicitation message is received, the anchored WTRU can determine to send a response message to the target UE.

[0145] When the anchored WTRU is within coverage, the IC anchored WTRU can check and determine whether the serving network (e.g., LMF) supports SIL positioning. The IC anchored WTRU can trigger a process to check for SIL positioning support. For example, the IC anchored WTRU can send a query message to the serving network via a NAS message regarding SIL positioning support (e.g., LMF version / release, supported SIL positioning features / capabilities, supported SIL releases). The LMF can send a response message via a NAS message containing information about SIL positioning. For example, the IC anchored WTRU can send a request indication and / or message to the serving network to provide SIL positioning support. Based on this request, the serving network can transmit a SIB message including one or more indications and / or information as a response message (e.g., LMF version / release, supported SIL positioning features / capabilities, supported SIL releases). The network can provide this information in response to the query regarding SIL positioning support. The service network may include one or more indications and / or information (e.g., LMF version / release version, supported SL positioning features / capabilities, supported SL release versions) in the cell-specific SIB messages (e.g., SIBs) broadcast.

[0146] Upon receiving a response message from the serving network, the OoC target WTRU can determine whether the serving network supports SL positioning. If the serving network does not support the required SL positioning, the IC anchored WTRU can determine not to send a response message to the target WTRU (e.g., Mode B discovery), or send a response message to the target WTRU with various reasons (e.g., an indication that the serving network does not support SL positioning). In another example, the IC anchored WTRU can send a response message to the target WTRU indicating that the serving network supports SL positioning but does not support ProSe L2 U2N relay operations.

[0147] The OoC target WTRU can learn about the serving network's support for SL positioning and the anchored WTRU's support (or capability) for ProSe L2 U2N relay operations for various reasons. These reasons can be beneficial, allowing the OoC target WTRU to determine subsequent steps. For example, upon receiving a response with a reason indicating that the serving network supports SL positioning and the anchored WTRU does not support ProSe L2 U2N relay operations, the OoC target WTRU can initiate the discovery of another IC anchored WTRU by sending a request message to that IC anchored WTRU to inquire about its support for ProSe L2 U2N relay operations.

[0148] If the serving network does not support the required SL location, the IC-anchored WTRU can determine to send a response discovery message (e.g., Mode B discovery) to the target WTRU.

[0149] Example transmission of discovery signals with relay support can be implemented.

[0150] When the IC-anchored WTRU determines that the serving network supports SL positioning, if the IC-anchored WTRU also supports or is capable of supporting ProSe L2 U2N trunk operations, the IC-anchored WTRU determines to perform trunk-assisted network-based operations. To support trunk-assisted network-based operations for the OoC target WTRU, the IC-anchored WTRU transmits discovery signals (e.g., announcements / responses), including a trunk association indication and / or parameters. The trunk indication (e.g., 1 bit) indicates that the IC-anchored WTRU supports ProSe L2 U2N trunk operations. The trunk association parameters include, for example, a trunk service code, an indicator providing ProSe L2 U2N trunking, and the WTRU role (e.g., anchored UE).

[0151] IC-anchored WTRUs can perform mode A and / or mode B discovery processes.

[0152] In Mode A, when the IC-anchored WTRU receives information that the serving network (e.g., LMF) supports SL positioning, the IC-anchored WTRU can broadcast an announcement message that includes indications and / or parameters supporting ProSe L2 U2N relay operation.

[0153] In Mode B, when the serving network (e.g., LMF) supports SL positioning, the IC-anchored WTRU can determine to send a response message to the target WTRU, which includes indications and / or parameters supporting ProSe L2 U2N relay operation.

[0154] When the OoC target WTRU receives a discovery message with indications and / or parameters supporting relay operation, the OoC target WTRU can determine to perform a relay-assisted network-based SL positioning operation. The OoC target WTRU establishes a PC5 unicast connection with the IC anchored WTRU based on a PC5 unicast link establishment process. After the PC5 unicast link is established, the IC anchored WTRU can send an SL-PRS signal to the OoC target WTRU. The OoC target WTRU can perform SL measurements based on the IC anchored WTRU's SL-PRS signal. The OoC target WTRU can deliver the SL measurements to the IC anchored WTRU, and the IC anchored WTRU can relay these SL measurements to the network to estimate the target WTRU's location.

[0155] Figure 6 This is a flowchart illustrating an example of a relay-assisted network-based process 600 performed by an anchored WTRU.

[0156] In step 602, the anchored WTRU determines to transmit the discovery message.

[0157] In step 604, it is determined whether the anchored WTRU is within coverage. If the anchored WTRU is not within coverage, then in step 618, the target WTRU determines to transmit an SL location discovery message with a reason, and process 600 ends.

[0158] If the anchored WTRU is detected to be within coverage in step 604, then in step 606, it is determined whether the serving network supports SL positioning. If the serving network does not support SL positioning, then in step 618, the target WTRU determines to transmit an SL positioning discovery message with a reason, and process 600 ends.

[0159] If the serving network is detected to support SL location in step 606, then in step 608, it is determined whether the anchored WTRU supports relay functionality. If the anchored WTRU does not support relay functionality, then in step 618, the target WTRU determines to transmit an SL location discovery message with a reason, and process 600 ends.

[0160] If it is determined in step 608 that the anchored WTRU supports relay functionality, then in step 610, the anchored WTRU determines to perform relay-assisted network-based operations in a PC scenario.

[0161] In step 612, the anchored WTRU transmits an SL location discovery message with a relay indication.

[0162] In step 614, the WTRU is anchored to transmit the SL-PRS.

[0163] Finally, in step 616, the anchored WTRU relays the measurement results from the target WTRU to the service network.

[0164] It can achieve service continuity for WTRUs targeting OoC.

[0165] Figure 7 This is a system diagram illustrating an example of service continuity for an OoC target WTRU. For example, the OoC target WTRU can support service continuity while performing SL positioning. When the OoC target WTRU receives an instruction from the IC anchor WTRU, it can terminate the ongoing SLPP session and (re)select an IC anchor WTRU. The OoC target WTRU can then establish a new indirect NAS connection via the (re)selected IC anchor WTRU. The WTRU can then re-establish its SLPP session with the network via the indirect NAS connection to the network through the (re)selected IC anchor WTRU.

[0166] A WTRU (e.g., an OoC target WTRU) can establish an indirect NAS connection via an IC anchored WTRU. Once the OoC target WTRU receives an instruction from the IC anchored WTRU, it can terminate an ongoing SLPP session and / or transaction, where the instruction may be a request to terminate SLPP. When an OoC target WTRU has multiple connections (e.g., SL-TDOA) with multiple IC anchored WTRUs, it can determine to perform an IC anchored WTRU reselection. The OoC target WTRU can establish a new indirect NAS connection via the (re)selected IC anchored WTRU and use the established indirect NAS connection to restart the terminated SLPP session and / or transaction. The OoC target WTRU can perform SL-PRS measurements with one or more anchored WTRUs (e.g., IC anchored WTRUs, OoC anchored WTRUs). The OoC target WTRU can report the SL-PRS measurement results to the serving network to estimate the location of the target WTRU.

[0167] The OoC target WTRU can receive SL positioning service requests (e.g., SL-MO-LR, 5GC-MO-LR) triggered by the SLPP layer of the target WTRU. An SL positioning service request is a request to measure the relative or absolute position of the OoC target WTRU. For measuring the position of the OoC target WTRU, SL-PRS measurement with the ability to receive SL-PRS signals is necessary. The OoC target WTRU must discover and select one or more anchored WTRUs to transmit SL-PRS signals.

[0168] The OoC target WTRU can establish a PC5 unicast connection with the initially selected IC anchor WTRU based on the PC5 unicast link establishment process. Once at least one IC anchor WTRU is selected, the OoC target WTRU can perform network-based operations because the IC anchor WTRU supports ProSe L2 U2N relay functionality, which enables the establishment of indirect NAS connections via ProSe L2 U2N relay. The OoC target WTRU and the network establish a Side Link Positioning Protocol (SLPP) session via the NAS connection.

[0169] When performing an SL positioning procedure between the LMF and the OoC target WTRU via an established SLPP session, the IC-anchored WTRU can send an indication (e.g., a request to terminate the ongoing SLPP session) to the OoC target WTRU. The IC-anchored WTRU can transmit this indication via a signal or message. For example, the indication can be transmitted in PHY layer signaling, in a field in the MAC CE, or via an RRC message (e.g., a PC5-RRC message).

[0170] During an SLPP session, the IC-anchored WTRU may send an indication when at least one or more of the following conditions are met.

[0171] Indications can be sent when a Uu radio link failure (RLF) is detected via an IC-anchored WTRU (e.g., in the RRC_CONNECTED state), when a T310 expires in the SpCell, when a random access problem indication is received from the MAC, or when an indication from the RLC that the maximum number of retransmissions has been reached. Indications can also be sent when the coverage state changes (e.g., from an IC-anchored WTRU to an OoC-anchored WTRU). Indications can also be sent during (re)selection between LMFs (e.g., in the RRC_IDLE or RRC_INACTIVE state) when it is detected that the serving network (e.g., the LMF) does not support SL positioning.

[0172] An example of establishing a new indirect NAS connection can be created.

[0173] The OoC target WTRU can have multiple connections to anchor WTRUs. When the OoC target WTRU performs an SLPP session for the SL-TDOA method, it may need to perform measurements on SL-PRS signals from at least three different anchor WTRUs. Depending on the SL positioning method, the OoC target WTRU may have to establish at least three candidate anchor WTRUs (e.g., OoC anchor WTRUs and / or IC anchor WTRUs). Upon receiving an instruction from an IC anchor WTRU, if the IC anchor is connected to multiple IC anchor WTRUs, the OoC target WTRU can determine to perform a candidate IC anchor WTRU (re)selection. When a candidate IC anchor WTRU supports relay functionality or operation, the OoC target WTRU can (re)select a candidate IC anchor WTRU. The OoC target WTRU can check whether the (re)selected IC anchor WTRU is supported.

[0174] If the check confirms that one or more (re)selected candidate IC anchored WTRUs support relay functionality, then SL measurement results from one or more candidate WTRUs need to be considered. For this comparison, the OoC target WTRU is (pre)configured (or configured by the network) with one or more thresholds for SL measurement results. For example, thresholds may include a threshold for SL-RSRP, a threshold for Uu-RSRP, and a threshold for Channel Busy Rate (CBR). The OoC target WTRU can determine to (re)select an IC anchored WTRU from the candidate IC anchored WTRUs based on one or more conditions or a combination of conditions. One condition could be that the Uu-RSRP measurement result (e.g., RSRP of SSB, CSI-RS, PRS) is higher than the (pre)configured Uu-RSRP threshold. Another condition could be that the SL-RSRP measurement result (e.g., RSRP of SL-SSB, SL-CSI-RS, SL-PRS) is higher than the (pre)configured SL-RSRP threshold. Another condition could be that the CBR measurement result is lower than the (pre)configured CBR threshold.

[0175] Even if more than one candidate IC anchored WTRU with relay support has a measurement value of SL measurement higher than the configured threshold, the OoC target WTRU can select the IC anchored WTRU with the highest value of the SL measurement result (e.g., the highest reported RSRP corresponding to the received SL CSI RS, or the highest reported RSRP corresponding to the SL-PRS).

[0176] After (re)selecting another IC anchored WTRU, the OoC target WTRU can initiate the establishment of a NAS connection via the newly (re)selected IC anchored WTRU. The OoC target WTRU can measure one or more SL-PRS transmitted from the IC anchored WTRU. After performing the SL-PRS measurement, the OoC target WTRU can report the SL-PRS measurement results to the serving network via the IC anchored WTRU. Based on the measurement results, the serving network (e.g., LMF) estimates the location of the target WTRU. The OoC target WTRU can determine to perform WTRU-based operation if at least one of the following conditions is met: The condition may be that there is no connection with another IC anchored WTRU (e.g., SL-RTT). Another condition may be that none of the connected IC anchored WTRUs support relay operation. Another condition may be that all established connections are with the OoC anchored WTRU.

[0177] Figure 8 This is a flowchart illustrating an example 800 of the service continuity process 800 performed by the OoC target WTRU.

[0178] In step 802, the OoC target WTRU receives an SL positioning request from the SLPP layer.

[0179] In step 804, the OoC target WTRU performs SL location discovery.

[0180] In step 806, the OoC target WTRU establishes a NAS connection to the service network via IC-anchored WTRU.

[0181] In step 808, the OoC target receives an instruction from the IC-anchored WTRU and terminates any ongoing SLPP sessions.

[0182] In step 810, it is determined whether the OoC target WTRU has multiple connections to the IC anchored WTRU. If the OoC target WTRU does not have multiple connections to the IC anchored WTRU, then in step 820, the OoC target WTRU determines to perform WTRU-only operation and performs discovery of the server WTRU. Process 400 ends.

[0183] If it is determined in step 810 that the OoC target WTRU has multiple connections to the IC anchored WTRU, then in step 812, the OoC target WTRU performs a reselection of another IC anchored WTRU.

[0184] In step 814, the OoC target WTRU establishes a NAS connection to the service network via the reselected IC anchored WTRU and restarts the terminated SLPP session.

[0185] In step 816, the OoC target WTRU performs SL-PRS measurements.

[0186] In step 818, the OoC target WTRU reports the SL measurement results to the service network via the reselected IC anchored WTRU.

Claims

1. A wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: The anchored WTRU is determined to support relay functionality for side link (SL) positioning, wherein the WTRU is located outside the network coverage area and wherein the anchored WTRU is located within the network coverage area; Based on the anchored WTRU supporting relay functionality, an indirect non-access stratum (NAS) connection to the network is established via the anchored WTRU. The network is confirmed to support SL positioning via the indirect NAS connection; and Based on the determination of SL positioning supported by the network, network-based operations are performed via the relay function of the anchored WTRU.

2. The WTRU of claim 1, wherein the processor is configured to: Based on the Proximity Service (ProSe) Layer 2 (L2) relay discovery process, it is determined that the anchored WTRU supports relay functionality.

3. The WTRU of claim 1, wherein, To determine that the anchored WTRU supports relay functionality for SL positioning, the processor is configured to: Send a request message to the anchored WTRU; and Receive a response message from the anchored WTRU, wherein the response message indicates that the anchored WTRU supports relay functionality for SL positioning.

4. The WTRU of claim 3, wherein the request message includes a capability query for relay functionality for SL positioning transmitted via a proximity-based Serving Communications 5 Radio Resource Control (PC5-RRC) connection.

5. The WTRU of claim 1, wherein the processor is configured to: SL-PRS measurements are performed based on the side link positioning reference signal (SL-PRS) received from the anchored WTRU.

6. The WTRU of claim 5, wherein the processor is configured to: The SL-PRS measurement results are transmitted to the network via the anchored WTRU to estimate the location of the WTRU.

7. The WTRU of claim 1, wherein, To determine that the network supports SL positioning, the processor is configured to: The anchored WTRU sends a query message to the network to determine whether the location management function (LMF) in the network supports SL positioning; and A response message is received from the LMF via the anchored WTRU, wherein the response message indicates that the network supports SL positioning.

8. The WTRU of claim 1, wherein the processor is configured to: The anchored WTRU is selected based on one or more SL measurements that are above a threshold.

9. The WTRU of claim 8, wherein the threshold includes the side link reference signal received power (SL-RSRP) value.

10. The WTRU of claim 1, wherein the processor is configured to: Detect the anchored WTRU near the stated WTRU.

11. A method for determining the location of a wireless transmit / receive unit (WTRU), comprising: The anchored WTRU is determined to support relay functionality for side link (SL) positioning, wherein the WTRU is located outside the network coverage area and wherein the anchored WTRU is located within the network coverage area; Based on the anchored WTRU supporting relay functionality, an indirect non-access stratum (NAS) connection to the network is established via the anchored WTRU. The network is confirmed to support SL positioning via the indirect NAS connection; and Based on the determination of SL positioning supported by the network, network-based operations are performed via the relay function of the anchored WTRU.

12. The method of claim 11, wherein determining that the anchored WTRU supports relay functionality is based on the Proximity Service (ProSe) Layer 2 (L2) relay discovery process.

13. The method of claim 11, wherein determining that the anchored WTRU supports relay functionality for SL positioning comprises: Send a request message to the anchored WTRU; as well as Receive a response message from the anchored WTRU, wherein the response message indicates that the anchored WTRU supports relay functionality for SL positioning.

14. The method of claim 13, wherein the request message comprises a capability query for relay functionality for SL positioning transmitted via a proximity-based Serving Communications 5 Radio Resource Control (PC5-RRC) connection.

15. The method of claim 11, wherein determining that the network supports SL positioning comprises: SL-PRS measurements are performed based on the side link positioning reference signal (SL-PRS) received from the anchored WTRU.

16. The method of claim 15, comprising: The SL-PRS measurement results are transmitted to the network via the anchored WTRU to estimate the location of the WTRU.

17. The WTRU of claim 11, wherein determining that the network supports SL positioning comprises: A query message is sent to the network via the anchored WTRU to determine whether the location management function (LMF) in the network supports SL positioning; as well as A response message is received from the LMF via the anchored WTRU, wherein the response message indicates that the network supports SL positioning.

18. The method of claim 11, wherein selecting the anchored WTRU comprises: The anchored WTRU is selected based on one or more SL measurements that are above a threshold.

19. The method of claim 18, wherein the threshold includes sidelink reference signal received power (SL-RSRP).

20. The method of claim 11, wherein determining the location of the WTRU comprises: Detect the anchored WTRU near the stated WTRU.

Images