System and method for rediscovery in location management function assisted sidelink positioning

Abstract

A first wireless transmit / receive unit (WTRU) includes a processor configured to determine to reject an SL positioning service request from a second WTRU. Based on determining to reject the SL location service request, the processor may send a service accept message to the second WTRU. The service acceptance message may include a pending indication that the first WTRU will determine whether the server WTRU can assist the SL location service request. The processor may send the SL positioning service information to the server WTRU, receive a rediscovery request from the server WTRU in response to the SL positioning service information, determine that the rediscovery request is unsuccessful, and / or send a first rejection message to the second WTRU. The first reject message may include one or more of a first cause code indicating a cause associated with the first reject message, a periodic timer, or a fallback time.

Description

[0001] Cross-reference to related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 586,594, filed September 29, 2023, the entire contents of which are incorporated herein by reference as if the application were fully set forth herein. Background Technology

[0002] 5G Location Services can provide functionality for providing location information for WTRUs. WTRU location can be supported by Radio Access Technology (RAT)-related location methods, which rely on, for example, 3GPP RAT measurements obtained from the target WTRU and / or measurements obtained by the access network from 3GPP RAT signals transmitted by the target WTRU. WTRU location can also be supported by RAT-independent location methods, which may rely on non-RAT measurements obtained from the WTRU and / or other information. Location information for one or more target WTRUs can be requested by a Location Services (LCS) client, an Application Function (AF) within or outside the 3GPP operator network, or a Control Plane Network Function (NF) within the 3GPP system, and reported to the Location Services (LCS) client, the Application Function (AF) within or outside the 3GPP operator network, or the Control Plane Network Function (NF) within the 3GPP system. For location requests from LCS clients or AFs, privacy (e.g., settings) checks on the target WTRU can be enabled to check whether it is permitted to obtain WTRU location information. Summary of the Invention

[0003] A first wireless transmit / receive unit (WTRU) may include a processor. The processor may be configured to: determine and reject a sidelink (SL) location service request from a second WTRU. The processor may be configured to: send a service acceptance message to the second WTRU based on the determination to reject the SL location service request. The service acceptance message may include, for example, a pending indication, indicating that the first WTRU will determine whether the server WTRU can assist the SL location service request. The processor may be configured to: send SL location service information to the server WTRU. The processor may be configured to: receive a rediscovery request from the server WTRU in response to the SL location service information. The processor may be configured to: determine that the rediscovery request is unsuccessful. The processor may be configured to: send a first rejection message to the second WTRU. The first rejection message may include, for example, one or more of a first cause code, a periodic timer, or a backoff time indicating the reason associated with the first rejection message.

[0004] In some examples, the processor may be configured to determine whether to reject an SL location service request from a second WTRU based on one or more of the following conditions: For example, the processor may determine to reject an SL location service request from a second WTRU based on the determination that the SL reference WTRU is not near the first WTRU. The processor may determine to reject an SL location service request from a second WTRU based on the determination that a previously discovered SL reference WTRU is no longer near the first WTRU. The processor may determine to reject an SL location service request from a second WTRU based on congestion experienced by the first WTRU on SL resources (e.g., the WTRU experiencing reduced Quality of Service (QoS) due to network capacity overload). The processor may determine to reject an SL location service request from a second WTRU based on the determination that a connection failure with the SL reference WTRU has occurred.

[0005] The first cause code may include, for example, an indication that: no SL reference WTRU is located near the first WTRU. The first cause code may include an indication that: not enough SL reference WTRUs are located near the first WTRU. The first cause code may include an indication that: the first WTRU is experiencing congestion on the SL resource. The first cause code may include an indication that: the first WTRU cannot establish a connection with the SL reference WTRU.

[0006] In some examples, the processor may be configured to send a second rejection message to the server WTRU in response to determining that the rediscovery request was unsuccessful. The second rejection message may include, for example, a second reason code associated with the rediscovery request.

[0007] The second cause code may include, for example, an indication that the SL reference WTRU has deployed power-saving technology and / or an indication that not enough SL reference WTRUs were found near the first WTRU.

[0008] In some examples, the processor can be configured to: determine that a rediscovery request failed based on latency requirements. The processor can be configured to: determine that a rediscovery request failed based on the power-saving mode of the first WTRU. The processor can be configured to: determine that a rediscovery request failed based on the number of rediscovery attempts used to identify one or more SL reference WTRUs, wherein the number of rediscovery attempts may be based on a timer value.

[0009] In some examples, the processor can be configured to receive SL location service requests from the second WTRU.

[0010] In some examples, the processor can be configured to discover one or more reference WTRUs based on SL location service requests.

[0011] In some examples, the processor can be configured to: discover a subset of the SL reference WTRU based on determining that the SL location service request is rejected. The processor can also be configured to: determine that a rediscovery request has failed based on a timer value.

[0012] In some examples, the processor may be configured to send SL location service information to the server WTRU for result inference based on a timer value indicating that the rediscovery request was unsuccessful. Result inference may include, for example, a list of identifiers associated with a subset of the SL reference WTRU and / or a list of capabilities associated with a subset of the SL reference WTRU.

[0013] A WTRU can be configured to perform a method comprising one or more of the following steps: The method may include: determining that a sidelink (SL) location service request from a second WTRU is rejected. The method may include: sending a service acceptance message to the second WTRU based on the determination that the SL location service request is rejected. The service acceptance message may include, for example, a pending indication that the first WTRU will determine whether the server WTRU can assist the SL location service request. The method may include: sending SL location service information to the server WTRU. The method may include: receiving a rediscovery request from the server WTRU in response to the SL location service information. The method may include: determining that the rediscovery request is unsuccessful. The method may include: sending a first rejection message to the second WTRU. The first rejection message may include, for example, a first reason code indicating the reason associated with the first rejection message, a periodic timer, or a backoff time.

[0014] In some examples, the method may include: determining to reject an SL location service request from a second WTRU based on one or more of the following conditions. For example, the method may include: determining to reject an SL location service request from a second WTRU based on the determination that the SL reference WTRU is not near the first WTRU. The method may include: determining to reject an SL location service request from a second WTRU based on the determination that a previously discovered SL reference WTRU is no longer near the first WTRU. The method may include: determining to reject an SL location service request from a second WTRU based on congestion experienced by the first WTRU on SL resources (e.g., the WTRU experiencing reduced Quality of Service (QoS) due to network capacity overload). The method may include: determining to reject an SL location service request from a second WTRU based on the determination that a connection failure with the SL reference WTRU has occurred.

[0015] The first cause code may include, for example, an indication that: no SL reference WTRU is located near the first WTRU. The first cause code may include an indication that: not enough SL reference WTRUs are located near the first WTRU. The first cause code may include an indication that: the first WTRU is experiencing congestion on the SL resource. The first cause code may include an indication that: the first WTRU cannot establish a connection with the SL reference WTRU.

[0016] In some examples, the method may include sending a second rejection message to the server WTRU in response to determining that the rediscovery request was unsuccessful. The second rejection message may include, for example, a second reason code associated with the rediscovery request.

[0017] The second cause code may include, for example, an indication that the SL reference WTRU has deployed power-saving technology and / or an indication that not enough SL reference WTRUs were found near the first WTRU.

[0018] In some examples, the method may include: determining that a rediscovery request was unsuccessful based on a delay requirement. The method may include: determining that a rediscovery request was unsuccessful based on a power-saving mode of a first WTRU. The method may include: determining that a rediscovery request was unsuccessful based on the number of rediscovery attempts used to identify one or more SL reference WTRUs, wherein the number of rediscovery attempts may be based on a timer value.

[0019] In some examples, the method may include receiving an SL location service request from a second WTRU.

[0020] In some examples, the method may include: discovering one or more reference WTRUs based on an SL location service request.

[0021] In some examples, the method may include: discovering a subset of the SL reference WTRU based on determining that the SL location service request is rejected. The method may also include: determining, based on a timer value, that the rediscovery request was unsuccessful.

[0022] In some examples, the method may include: based on a timer value determining that a rediscovery request was unsuccessful, sending SL location service information to a server WTRU for result inference. Result inference may include, for example, a list of identifiers associated with a subset of the SL reference WTRU and / or a list of capabilities associated with a subset of the SL reference WTRU. Attached Figure Description

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

[0024] Figure 1B The illustration is based on an embodiment and can be used Figure 1A The diagram shows a system diagram of an exemplary wireless transmit / receive unit (WTRU) used in a communication system.

[0025] Figure 1C The illustration is based on an embodiment and can be used Figure 1A The diagram shows an exemplary radio access network (RAN) and an exemplary core network (CN) used within a communication system.

[0026] Figure 1D The illustration is based on an embodiment and can be used Figure 1A The diagram shows another exemplary RAN and another exemplary CN used within the communication system.

[0027] Figure 2 This is a block diagram illustrating an exemplary reference model of a next-generation radio access network for location services.

[0028] Figure 3 This is a schematic diagram illustrating an exemplary sidelink localization operation assisted by LMF and in which a detection failure occurs at the target WTRU.

[0029] Figure 4 This is a schematic diagram illustrating an exemplary SL positioning operation where a discovery failure occurs at the SL target WTRU, assisted by the SL positioning server WTRU.

[0030] Figure 5 This is a schematic diagram illustrating an exemplary SL location operation assisted by the SL location server WTRU when a discovery failure occurs on the SL server WTRU. Detailed Implementation

[0031] Figure 1A This is a diagram illustrating an exemplary communication system 100 that may implement one or more of the disclosed embodiments. 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 this 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 Spread Spectrum OFDM (ZT UW DTS-s OFDM), Unique Word OFDM (UW-OFDM), Resource Block Filtered OFDM, Filter Library Set Multicarrier (FBMC), etc.

[0032] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, Public Switched Telephone Network (PSTN) 108, Internet 110, and other networks 112. However, it will be understood that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. As an 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 WTRU in WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a WTRU.

[0033] The communication system 100 may also include base station 114a and / or base station 114b. Each of the base stations 114a and 114b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c, and 102d to facilitate access to one or more communication networks (such as CN 106 / 115, the Internet 110, and / or other networks 112). As an example, base stations 114a and 114b may be base transceivers (BTS), Node-B, eNode B, home Node B, home eNode B, gNB, NR Node B, field controllers, access points (APs), wireless routers, etc. Although base stations 114a and 114b are described 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.

[0034] 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 of a specific geographic area, which may be relatively fixed or may change over time. A cell may be further divided into cell sectors. For example, the cell associated with base station 114a may be divided into three sectors. Therefore, in one embodiment, base station 114a may include three transceivers, i.e., one transceiver for each sector of the cell. In embodiments, base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell. For example, beamforming can be used to transmit and / or receive signals in a desired spatial direction.

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

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

[0037] In the embodiment, base station 114a and WTRUs 102a, 102b, 102c can implement radio technologies such as evolved UMTS terrestrial radio access (E-UTRA), which can use Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) and / or LTE-Advanced Pro (LTE-A Pro) to establish air interface 116.

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

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

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

[0041] 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 use any suitable RAT to facilitate wireless connectivity in a local area, such as commercial locations, homes, vehicles, campuses, industrial facilities, air corridors (e.g., used by drones), roads, 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 another 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 use cellular-based RATs (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR, etc.) to establish picocells or femtocells. Figure 1A As shown, base station 114b can have a direct connection to the Internet 110. Therefore, base station 114b may not need to access the Internet 110 via CN 106 / 115.

[0042] 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 WTRUs of WTRUs 102a, 102b, 102c, and 102d. Data may have varying Quality of Service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, mobility requirements, etc. CN 106 / 115 can provide call control, billing services, mobile location-based services, prepaid telephony, Internet connectivity, video distribution, etc., and / or perform advanced security functions such as user authentication. Although not mentioned in Figure 1A As shown, but will be understood, RAN 104 / 113 and / or CN 106 / 115 may communicate directly or indirectly with other RANs that use the same RAT as or a different RAT than RAN 104 / 113. For example, in addition to being connected to RAN 104 / 113, which may use NR radio technology, CN 106 / 115 may also communicate with another RAN (not shown) that uses GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, or WiFi radio technology.

[0043] CN 106 / 115 can also serve 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 globally interconnected computer network and apparatus system 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.

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

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

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

[0047] Transmitting / receiving element 122 may 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 may be an antenna configured to transmit and / or receive RF signals. In embodiments, for example, transmitting / receiving element 122 may be a transmitter / detector configured to transmit and / or receive IR, UV, or visible light signals. In another embodiment, transmitting / receiving element 122 may be configured to transmit and / or receive both RF and optical signals. It will be understood that transmitting / receiving element 122 may be configured to transmit and / or receive any combination of wireless signals.

[0048] Although the transmitting / receiving element 122 is in Figure 1B While described 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.

[0049] 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 described above, WTRU 102 may have multi-mode capability. Therefore, transceiver 120 may include multiple transceivers to enable WTRU 102 to communicate over various RATs (such as, for example, NR and IEEE 802.11).

[0050] The processor 118 of WTRU 102 can be coupled to a speaker / microphone 124, a keypad 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 the speaker / microphone 124, keypad 126, and / or display / touchpad 128. The processor 118 can also output user data to the speaker / microphone 124, keypad 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 said 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, a memory stick, a secure digital storage (SD) card, etc. In other embodiments, processor 118 may access information from memory that is not physically located on WTRU 102 (such as on a server or home computer (not shown)) and store the data in said memory.

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

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

[0053] 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 videos), Universal Serial Bus (USB) ports, vibration devices, television transceivers, hands-free headsets, Bluetooth® modules, frequency modulation (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.

[0054] WTRU 102 may include a full-duplex radio for which the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of 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 through hardware (e.g., a choke) or through signal processing (e.g., a separate processor (not shown) or through processor 118). In embodiments, WTRU 102 may include a half-duplex radio for which the transmission and reception of some or all of the signals (e.g., associated with a specific subframe of either UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

[0056] RAN 104 may include eNode-Bs 160a, 160b, and 160c, but it will be understood that RAN 104 may include any number of eNode-Bs while remaining consistent with the embodiments. Each eNode-B 160a, 160b, and 160c may 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.

[0057] 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 scheduling of users 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.

[0058] Figure 1C 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. Although each of the foregoing elements is described 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.

[0059] The MME 162 can be connected to each of the eNode-Bs 162a, 162b, and 162c in RAN 104 via the S1 interface and can be used as a control node. For example, the MME 162 can be responsible for authenticating users of WTRUs 102a, 102b, and 102c, activating / deactivating bearers, 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).

[0060] The SGW 164 can be connected 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 packets to / from WTRUs 102a, 102b, and 102c. The SGW 164 can also perform other functions, such as anchoring the user plane during inter-eNode B handovers, 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.

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

[0062] CN 106 can facilitate 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 landline communication devices. For example, CN 106 may include an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server), or can communicate with said IP gateway, which serves 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.

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

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

[0065] A WLAN in an Infrastructure Basic Services Set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may access a Distribution System (DS) or another type of wired / wireless network, or have an interface with 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 delivered to the AP via the AP. Traffic originating from a STA destined for a destination outside the BSS can be sent to the AP for delivery to the appropriate destination. Traffic between STAs within the BSS can be transmitted 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 may be considered and / or referred to as peer-to-peer traffic. Using Direct Link Establishment (DLS), peer-to-peer traffic can be transmitted between source and destination STAs (e.g., directly between source and destination STAs). In some representative embodiments, the DLS may use 802.11e DLS or 802.11z Tunneled DLS (TDLS). WLANs using Standalone BSS (IBSS) mode may not have access points (APs), and STAs within the IBSS or using the IBSS (e.g., all STAs within a STA) can communicate directly with each other. IBSS communication mode may sometimes be referred to here as "ad-hoc" communication mode.

[0066] When operating in 802.11ac infrastructure mode or a similar 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 20 MHz bandwidth) or dynamically set via signaling. The primary channel can be the operating channel of the BSS and can be used by the STA to establish a connection with the AP. In some representative embodiments, such as in an 802.11 system, carrier-sense multiple access (CSMA / CA) with collision avoidance can be implemented. For CSMA / CA, each STA (including the AP) can sense the primary channel. If the primary channel is sensed / detected and / or determined to be busy by a particular STA, that particular STA can back off. In a given BSS, one STA (e.g., only one station) can transmit at any given time.

[0067] For example, a high-throughput (HT) STA can communicate using a 40 MHz wide channel by combining a primary 20 MHz channel with adjacent or non-adjacent 20 MHz channels.

[0068] Very High Throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining adjacent 20 MHz channels. A 160 MHz channel can be formed by combining eight adjacent 20 MHz channels, or by combining two non-adjacent 80 MHz channels (this can be referred to as an 80+80 configuration). For the 80+80 configuration, after channel coding, data is delivered via a segment resolver, which 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 80 MHz channels, and the data can be transmitted by the transmitting STA. 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).

[0069] Sub-1 GHz operating modes are supported by 802.11af and 802.11ah. In 802.11af and 802.11ah, the channel operating bandwidth and carrier 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, and 802.11ah supports 1 MHz, 2 MHz, 4 MHz, 8 MHz, and 16 MHz bandwidths using non-TVWS spectrum. According to a representative embodiment, 802.11ah may support instrument-type control / machine-type communication, such as MTC devices in macro coverage areas. MTC devices may have certain capabilities, such as limited capabilities, including support (e.g., only support) certain and / or limited bandwidths. MTC devices may include batteries with a battery life exceeding a threshold (e.g., to maintain a very long battery life).

[0070] WLAN systems that 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 may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by the STA that supports the minimum bandwidth operating mode among all STAs operating in the BSS. In the example of 802.11ah, for STAs that support (e.g., only support) the 1MHz mode (e.g., MTC type devices), the primary channel may be 1 MHz wide even if the AP and other STAs in the BSS support 2 MHz, 4 MHz, 8 MHz, 16 MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or Network Assignment Vector (NAV) settings may depend on the status of the primary channel. If, for example, the primary channel is busy due to a STA (that only supports the 1 MHz operating mode) transmitting to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

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

[0073] RAN 113 may include gNBs 180a, 180b, and 180c, but 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 use 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 embodiments, 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 may be on unlicensed spectrum, while the remaining component carriers may be on licensed spectrum. In embodiments, gNBs 180a, 180b, and 180c can implement Coordinated Multipoint (CoMP) technology. For example, WTRU 102a can receive coordinated transmissions from gNBs 180a and 180b (and / or gNB 180c).

[0074] Using transmissions associated with scalable digital theory, WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c. For example, the OFDM symbol spacing and / or OFDM subcarrier spacing can vary for different transmissions, different cells, and / or different portions of the radio transmission spectrum. Using various or scalable length subframes or transmission time intervals (TTIs) (e.g., containing a varying number of OFDM symbols and / or an absolute time of continuously varying length), WTRUs 102a, 102b, and 102c can communicate with gNBs 180a, 180b, and 180c.

[0075] 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 also accessing other RANs (e.g., eNode-Bs 160a, 160b, and 160c). In standalone configuration, WTRUs 102a, 102b, and 102c can use one or more gNBs from 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 also 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 be used as mobility anchors for WTRU 102a, 102b, and 102c, and gNB 180a, 180b, and 180c can provide additional coverage and / or throughput for serving WTRU 102a, 102b, and 102c.

[0076] Each gNB in ​​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, interoperability between NR and E-UTRA, routing of user plane data to User Plane Functions (UPF) 184a and 184b, routing of control plane information to Access and Mobility Management Functions (AMF) 182a and 182b, etc. Figure 1D As shown, gNB 180a, 180b, and 180c can communicate with each other via the Xn interface.

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

[0078] AMF 182a and 182b can be connected to one or more gNBs (gNBs) 180a, 180b, and 180c in RAN 113 via the N2 interface and can be used as control nodes. For example, AMF 182a and 182b can be responsible for authenticating users of WTRU 102a, 102b, and 102c, supporting network slices (e.g., handling different PDU sessions with different requirements), selecting specific SMF 183a 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 type of services used by WTRU 102a, 102b, and 102c. For example, different network slices can be established for different use cases, such as services relying on Ultra Reliable Low Latency (URLLC) access, services relying on Enhanced Massive Mobile Broadband (eMBB) access, and services for Machine Type Communication (MTC) access. AMF 162 can provide control plane functions for switching between RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0079] SMF 183a and 183b can be connected to AMF 182a and 182b in CN 115 via the N11 interface. SMF 183a and 183b can also be connected 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 the routing of services through UPF 184a and 184b. 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, or Ethernet-based.

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

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

[0082] Considering Figure 1A-1D and Figure 1A-1D The corresponding descriptions herein regarding WTRU 102a-d, base station 114a-b, eNode-B 160a-c, MME 162, SGW 164, PGW 166, gNB 180a-c, AMF 182a-ab, UPF 184a-b, SMF183a-b, DN 185a-b, and / or any other device(s) described herein, and / or the functions described herein, may be performed by one or more emulation devices (not shown). An emulation device may be one or more devices configured to emulate one or more 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.

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

[0084] While not implemented / deployed as part of a wired and / or wireless communication network, the one or more simulation devices may perform the one or more functions (including all functions). For example, the simulation devices may be used in test scenarios in test laboratories and / or non-deployed (e.g., test) wired and / or wireless communication networks to perform testing of one or more components. The one or more simulation devices may be test equipment. Wireless communication via direct RF coupling and / or through an RF circuit system (e.g., the RF circuit system may include one or more antennas) may be used by the simulation devices to transmit and / or receive data.

[0085] When the target WTRU of an SL performs a discovery procedure to find the reference WTRU of the SL, it may not find any reference WTRU of the SL. In this case, depending on the request, for example if SL-MT-LR, the WTRU may send an error code to the Location Management Function (LMF) indicating "Reference WTRU not found", and / or if it is requested by the client WTRU of the SL, the WTRU may send a rejection message to the client WTRU with the error code "Reference WTRU not found".

[0086] When the target SL WTRU performs a discovery procedure to discover the SL reference WTRU, it may not find enough SL reference WTRUs required for each positioning requirement. In this case, the WTRU notifies the LMF and / or the side-link (SL) positioning server WTRU by including a list of SL reference WTRUs that may have been discovered and / or a list of WTRUs that may not have been discovered. Based on the received list, the LMF and / or the SL positioning server WTRU requests the target SL WTRU to perform a rediscovery by providing a rediscovery instruction and / or additional parameters (such as a retry timer and the minimum number of SL reference WTRUs required). The WTRU may also provide an instruction to abort the procedure.

[0087] When the target WTRU (SL) sends a location service request, the SL location server may be unable to assist the SL location request because it may be overloaded (e.g., congested), too far away to meet the required location accuracy and latency, and / or may become unavailable due to mobility. In this case, the SL location server may send a rejection message to the target WTRU, stating the appropriate reason code as the reason for rejection (e.g., "SL location server WTRU unavailable," "SL location server cannot meet location request," "congestion," and / or "connection unavailable").

[0088] Several different types of location requests are supported.

[0089] The first location request can be a Mobile Termination Location Request (MT-LR), in which the LCS client or AF can send a location request to the 5G network for the location of the target WTRU.

[0090] The second location request can be a Mobile Initiated Location Request (MO-LR), in which the WTRU can send a request to the 5G network for location-related information about the WTRU.

[0091] A third location request can be an immediate location request, in which the LCS client or AF can send or initiate a location request for (one or more) target WTRUs and can expect to receive a response containing location information for (one or more) target WTRUs within a short period of time. Immediate location requests can be used with MT-LR or MO-LR.

[0092] The fourth location request can be a deferred location request, in which the LCS client or AF can send a location request to the 5G network for one or more target WTRUs and can expect to receive a response when the indicated event occurs at the target WTRU at some future time. Deferred location requests can be used with MT-LR.

[0093] Figure 2 This is a block diagram illustrating an exemplary reference model 200 for a next-generation radio access network used for location services. Figure 2 In this context, (R)AN can represent a Next Generation Radio Access Network (NG-RAN), a Trusted Non-3GPP Access Network, or an Untrusted Non-3GPP Access Network. This access network can participate in handling various location procedures, including the location of a target WTRU, the provision of location-related information not associated with a specific target WTRU, and / or the transmission of location messages between the AMF or LMF and the target WTRU.

[0094] AF and NF can access LCS services from the Gateway Mobile Location Center (GMLC) in the same 3GPP operator network.

[0095] LCS clients can access LCS services from GMLC, and external AFs can access LCS services from the Network Exposure Function (NEF).

[0096] GMLC can handle requests from external LCS clients and AFs. If the AF is external, the requests from the AF are handled by the NEF, and GMLC can forward location requests to the appropriate NF.

[0097] Location retrieval function (LRF) can be used to retrieve or verify location information, and can be located in the same location as GMLC or be separate from it.

[0098] The Location Management Function (LMF) manages the overall coordination and scheduling of resources required for the location of WTRUs registered to or accessing the 5G Core Network (5GCN). The LMF can estimate or verify the accuracy of last location-related information.

[0099] Location services based on sidelinks (SL) can be implemented.

[0100] SL positioning can be defined as using PC5 to locate a WTRU to obtain absolute position, relative position, or ranging information. Ranging refers to determining the distance between two or more WTRUs and / or the direction of one WTRU (e.g., the target WTRU) relative to another WTRU (e.g., the reference WTRU) via the PC5 interface.

[0101] For SL positioning purposes, one or more of the following definitions may be applied.

[0102] SL target WTRU and / or target WTRU can refer to a WTRU in which an SL is used to measure its distance, orientation and / or position in range-based services and SL positioning, with the support of one or more SL reference WTRUs.

[0103] A located WTRU can refer to an SL reference WTRU, an SL positioning reference WTRU, and / or a reference WTRU, the location of which is known or can be determined using Uu-based positioning. A located WTRU can be used to determine the location of a target WTRU using SL positioning.

[0104] SL reference WTRU can refer to a WTRU that supports the positioning of a target WTRU, for example, by using SL to transmit and / or receive reference signals for positioning, provide positioning-related information, etc.

[0105] SL positioning client WTRU, SL client WTRU and / or client WTRU may refer to a third-party WTRU other than the SL reference WTRU or target WTRU, which is the application residing on the third-party WTRU that initiates ranging and / or SL positioning service requests.

[0106] Ranging and / or SL positioning operations can be performed as network-assisted operations or WTRU-only operations. In network-assisted operations, one or more 5G core (5GC) NFs can participate in service request processing and result inference. In WTRU-only operations, service request processing and result inference operations can be performed by the WTRU.

[0107] When network-assisted operations are used, the Location Management Function (LMF) defined in 5G Location Services can support triggering SL positioning, coordinating SL positioning operations, and delivering results to the client. Ranging and / or SL positioning service requests can be initiated by WTRU (e.g., SL positioning client WTRU, target WTRU, SL reference WTRU), 5GC NF, LCS client, or AF.

[0108] When only WTRU operation is used, WTRUs can interact with each other via PC5 as needed to perform SL positioning operations. An SL positioning server WTRU can be defined as coordinating SL positioning operations and the estimation of positioning results. SL positioning server WTRUs (e.g., SL server WTRU, positioning server WTRU, server WTRU) can provide method determination, auxiliary data allocation, and / or location estimation functions for SL positioning and ranging-based services.

[0109] Network (NW) assisted SL localization can be achieved.

[0110] NW-assisted SL positioning can be used to estimate the location of a WTRU by means of a network using the locations of one or more located WTRUs and the distance and / or direction between the WTRU and (one or more) located WTRUs.

[0111] The NW-assisted SL positioning feature can be implemented when the WTRU is able to establish a NAS (Non-Access Layer) signaling connection, and / or when the WTRU is unable to establish a NAS signaling connection.

[0112] When the WTRU is able to establish a NAS connection, it can enter the CM-Connected state by executing a WTRU-triggered service request to 5GC-MO-LR or a network-triggered service request to 5GC-NI-LR or 5GC-MT-LR. Because the target WTRU can establish a NAS signaling connection with the AMF, the functions specified in the 5G location service can be reused, including, for example, 5GC-MO-LR, 5GC-MT-LR, and / or 5GC-NI-LR.

[0113] Once a network connection can be established, one or more of the following principles may apply. The target WTRU or LMF can determine whether network-assisted SL positioning will be applied. The target WTRU can discover one or more located WTRUs for network-assisted SL positioning. The target WTRU and one or more located WTRUs can perform ranging and / or SL positioning. The target WTRU may include WTRU identifiers for one or more located WTRUs for the LMF, as well as ranging measurement data or estimation results. The LMF can interact with the GMLC to obtain the locations of the located WTRUs. The LMF can estimate the location of the target WTRU using the locations of one or more located WTRUs and the ranging and / or SL positioning measurement data and / or estimation results reported by the target WTRU and / or the located WTRUs.

[0114] When a target WTRU cannot establish a NAS connection with the AMF due to its location outside coverage or any other reason (e.g., invalid subscription, rejected by NW), the following principles apply. The target WTRU can perform discovery and / or selection of the located WTRU. The target WTRU can transmit its ranging measurements / results to one or more located WTRUs. One or more located WTRUs can report ranging and / or SL positioning measurement results to the LMF. This report may include ranging measurements / results received from the target WTRU. The endpoints of the LPP message are the LMF and one or more located WTRUs. The LMF can use the received information to estimate the location of the target WTRU, and / or provide the obtained location to the target WTRU via the located WTRU or to the LCS client or application server via the 5G NF.

[0115] The SL location service can be exposed to one or more WTRUs.

[0116] A WTRU (e.g., an SL positioning client WTRU) can request SL positioning via PC5 or NW. When an SL positioning client WTRU requests SL positioning services via a PC5 connection, it can discover one of multiple reference WTRUs and multiple target WTRUs. The SL positioning client WTRU can initiate ranging and / or SL positioning service requests to the discovered reference WTRUs and target WTRUs to obtain ranging and / or SL positioning results between the reference WTRUs and target WTRUs. This request may include user information for the SL positioning client UE, reference UEs, and / or target UEs. Upon receiving the SL positioning service request, SL positioning service operations with the LMF and / or SL positioning server WTRU can be performed.

[0117] Error handling for SL positioning procedures can be implemented.

[0118] By coordinating with the SL positioning server UE or LMF, the reference WTRU and target WTRU can perform SL positioning, with the SL positioning server UE or LMF assisting in estimating and distributing the positioning results. When (e.g., only if) the target WTRU and reference WTRU are outside coverage (without NAS connectivity), the SL positioning server WTRU can be used unless the LMF recommends that the SL positioning server take over. When either the reference WTRU or the target WTRU is within coverage (with NAS connectivity), the LMF can participate. If the target WTRU is within coverage, it can contact the LMF for coordination. Furthermore, if the reference WTRU is within coverage and the target WTRU is outside coverage, the SL reference WTRU can contact the LMF for coordination.

[0119] When a target WTRU receives a location request from an LMF (MT-LR) or SL client WTRU (MO-LR), the target WTRU can discover and / or select one or more located WTRUs and / or SL reference WTRUs for ranging and / or SL location procedures. There may be scenarios where the target WTRU or client WTRU fails to discover any target WTRU, SL location server WTRU, or SL reference WTRU. This scenario could be due to several reasons, including: the distance between WTRUs is too large, causing the SNR to fall below the required threshold; WTRUs are experiencing congestion (e.g., reduced Quality of Service (QoS) due to network capacity overload); high mobility, etc. Similarly, there may be scenarios where the target WTRU discovers some SL reference WTRUs, but not enough to perform the expected location accuracy.

[0120] Alternatively, the SL target WTRU or SL client WTRU may be in a power-saving mode, which may prevent continuous or more frequent searches of the SL target WTRU, SL location server WTRU, or SL reference WTRU.

[0121] Considering the above, the following issues may need to be addressed.

[0122] The first question might be: How should the target WTRU handle SL reference WTRU discovery failure? The second question might be: How should the target WTRU handle SL location server WTRU discovery failure? The third question might be: How should the LMF / SL location server WTRU handle SL reference WTRU discovery failure when it occurs at the target WTRU?

[0123] This disclosure may assume that the WTRU supports PC5 signaling (WTRU with 5G ProSe functionality). The ProSe (proximity-based service) layer in the WTRU may support this PC5 signaling.

[0124] WTRUs may have ranging and / or SL positioning capabilities and / or SL positioning server WTRU capabilities. Here, SL positioning may refer to positioning via the PC5 interface, and ranging may refer to determining the distance between two or more WTRUs and / or the orientation and / or relative positioning of one WTRU relative to another WTRU.

[0125] The rediscovery of the SL reference WTRU used for LMF-assisted SL positioning procedures can be achieved.

[0126] For example, in the SL-MT-LR protocol, an SL target WTRU (WTRU1) can be triggered for a location request via AF or LCS. As requested by the LMF, the SL target WTRU may attempt to discover SL reference WTRUs and / or SL-located WTRUs for location operations. However, the SL target WTRU may not be able to locate any or enough SL reference WTRUs. In this case, the SL target WTRU may send an error message to the LMF, or send a list of discovered and undiscovered SL reference WTRUs, along with the capabilities of the SL reference WTRUs. Based on the received WTRU IDs, capabilities, and / or location requests, the LMF may instruct the SL target WTRU to perform rediscovery within a certain time window until the expected number of SL reference WTRUs are discovered.

[0127] In the SL-MO-LR protocol, the SL target WTRU (WTRU1) can be triggered for location requests. The SL target WTRU can then receive a set of parameters from the LMF as part of its configuration, which the SL target WTRU uses to handle failures.

[0128] Figure 3 This is a schematic diagram illustrating an exemplary sidelink location operation 300 assisted by LMF and in which a detection failure occurs at the target WTRU.

[0129] like Figure 3 As shown, the SL target WTRU (WTRU1) can be triggered for a location request. In 0a, the location request can be triggered by the AF or LCS. In 0b, WTRU1 can receive messages from the LMF via the serving AMF. This SL-MT-LR request may include the application layer IDs of other WTRUs (WTRU2 to WTRUUn), the type of the desired location result (e.g., relative location or distance and / or direction), one or more SL reference WTRUs for the relative location, a timer value (for retrying or backoff), a delay requirement, a minimum number of reference WTRUs determined based on the location request, and / or a minimum number of located WTRUs.

[0130] In step 1, if the LMF provides application layer IDs for other WTRUs (WTRU2 to WTRUUn), the SL target WTRU (WTRU1) can attempt to discover other WTRUs using their application layer IDs. If the LMF does not provide WTRU IDs, the SL target WTRU can perform open discovery, for example, to discover the SL reference WTRU.

[0131] The target WTRU of SL may find: (1) all reference WTRUs (WTRU2-WTRUUn) provided by LMF in step 0b; (2) a subset of WTRUs, i.e. x WTRUs; (3) one or more other reference WTRUs not in the list provided by LMF; and (4) no WTRUs requested by LMF in step 0b.

[0132] In step 2, WTRU1 can acquire one or more capabilities of the discovered WTRU.

[0133] In step 3, WTRU1 can return a supplemental service SL-MT-LR response to the service AMF in a UL NAS TRANSPORT message. This response may include a list of discovered WTRUs (using application layer IDs and / or GPSI), a list of newly discovered WTRUs (which are not in the list of WTRU IDs received from the LMF), and / or one or more error codes with cause values ​​(e.g., no reference WTRU found, too few reference WTRUs found, specific WTRU unavailable, WTRU not authorized for discovery). Target WTRUs can share the capabilities of discovered WTRUs.

[0134] In section 4, the serving AMF may forward the SL-MT-LR response to the LMF. The SL-MT-LR response may include a list of discovered WTRUs (using application layer IDs and / or GPSI), their capabilities, a list of newly discovered WTRUs (which are not in the list of WTRU IDs received from the LMF), and / or one or more error codes with cause values ​​(e.g., no reference WTRU found, too few reference WTRUs found, specific WTRU unavailable, WTRU not authorized for discovery).

[0135] In step 5, the LMF can receive a list of discovered SL reference WTRUs, and based on the positioning requirements, the LMF can determine whether the SL target WTRU has discovered enough SL reference WTRUs / located WTRUs. If the SL target WTRU has not discovered enough SL reference WTRUs / located WTRUs, the LMF can request the SL target WTRU to perform rediscovery of SL reference WTRUs (e.g., find more WTRUs if possible).

[0136] LMF can provide one or more of the following to the SL target WTRU: timer value, one or more delay requirements, and / or minimum number of SL reference WTRUs.

[0137] The timer value can be provided by the LMF, so the SL reference WTRU can be found by the SL target WTRU within a certain window until the expected number is reached (e.g., a periodic timer for performing periodic attempts, an explicit maximum time value for cases with strict delay requirements, and / or a backoff timer for backing down if the expected result is not achieved automatically).

[0138] Latency requirements can be correlated with the location of the expected location service (e.g., maximum tolerable latency, meaning that the location response does not take too long for any mission-critical service).

[0139] The minimum number of SL reference WTRUs can be associated with the expected location service.

[0140] In step 6, the LMF can send an SL-MT-LR request to the serving AMF as a supplemental service message. The SL-MT-LR request may include a rediscovery indication, a timer value, a list of new SL reference WTRUs / located WTRUs, a minimum number of SL reference WTRUs, and / or the required capacity of the SL reference WTRUs.

[0141] In 7, for example, using the DL NAS TRANSPORT message, the service AMF can forward an SL-MT-LR request to WTRU1. The forwarded SL-MT-LR request may include a rediscovery indication, a timer value, a list of new SL reference WTRUs / located WTRUs, a minimum number of SL reference WTRUs, and / or the required capacity of the SL reference WTRUs.

[0142] In step 8, the SL target WTRU can receive a rediscovery request from the LMF. Based on the received parameters, the SL target WTRU can perform rediscovery, start a corresponding timer, and continue retrying until the timer expires, until the request is met, as indicated in step 7. The request may refer to a minimum number of SL reference WTRUs with the capabilities required for the expected SL location service. For example, when the expected number is reached, the SL target WTRU can send a list of new SL reference WTRUs to the LMF.

[0143] In 5-8, as an alternative, if another target WTRU exists nearby, the LMF can query the other target WTRU and initiate a sidelink positioning operation 300 with the newly selected target WTRU.

[0144] In the SL-MT-LR request, the LMF may send a new set of parameters as part of the configuration message. This new set of parameters may include timer values, a list of SL reference WTRUs / located WTRUs, a minimum number of SL reference WTRUs, the required capacity of SL reference WTRUs for each location service, and / or the number of SL reference WTRUs required, which may vary depending on QoS or the location method.

[0145] If there is no NAS connection or the LMF has instructed the SL positioning server WTRU to assist in positioning, the sidelink positioning operation 300 can be coordinated by the SL positioning server WTRU.

[0146] As an example, within the rediscovery of SL reference WTRUs in the LMF-assisted SL positioning procedure, the LMF may receive a list of undiscovered WTRUs (based on WTRU IDs received from the LMF) and / or one or more error codes with cause values ​​(e.g., no reference WTRU found, too few reference WTRUs found).

[0147] Based on the positioning requirements and information from the target WTRU in the SL, the LMF can determine whether the target WTRU in the SL has found enough reference WTRUs / located WTRUs.

[0148] The LMF can send a request to the SL target WTRU to perform the rediscovery of the SL reference WTRU (to find more WTRUs if possible). The LMF can provide one or more additional parameters to the SL target WTRU, such as rediscovery indication, timer value, delay requirement, list of new SL reference WTRUs / located WTRUs, minimum number of SL reference WTRUs, and / or the required capacity of the SL reference WTRUs.

[0149] As an alternative, LMF may send a new set of parameters as part of the configuration message. This new set of parameters may include timer values, a list of SL reference WTRUs / located WTRUs, a minimum number of SL reference WTRUs, and / or the required capacity for each SL reference WTRU in the location service.

[0150] As an example, in the rediscovery of SL reference WTRUs in the LMF-assisted SL positioning procedure, the SL target WTRU may send a list of undiscovered WTRUs (based on the UE ID received from the LMF) and / or one or more error codes with cause values ​​(e.g., no reference WTRU found, too few reference WTRUs found) to the LMF via the AMF in a NAS message.

[0151] The SL target WTRU can receive a request from the LMF via the AMF in a DL NAS TRANSPORT message to perform a rediscovery. This request has a rediscovery indication and additionally includes a timer value, a list of new SL reference WTRUs / located WTRUs, a minimum number of SL reference WTRUs, and / or the required capacity of the SL reference WTRUs.

[0152] Based on the received parameters, the SL target WTRU can perform rediscovery, start the appropriate timer, and / or continue retrying until the request is met. For example, when the expected number is reached, the SL target WTRU can send a new list of SL reference WTRUs to the LMF.

[0153] Procedures for SL location service operations based on the interaction between the client WTRU (e.g., SL client WTRU) and the SL location server WTRU can be implemented.

[0154] The SL client WTRU can trigger an SL location request to the SL target WTRU. Based on the location request, the SL target WTRU initiates a discovery procedure for the discovery of the SL reference WTRU / SL located WTRU. The discovery procedure may succeed or may fail because the SL target WTRU is congested, no SL reference WTRU is found, and / or not enough SL reference WTRUs are found for the location service.

[0155] If the procedure is found to be unsuccessful, the target WTRU may reject the location request from the client WTRU by sending a rejection message with an error code and a reason value. Alternatively, if the procedure is found to be unsuccessful, the SL target WTRU may not send (e.g., not immediately) a rejection message, but instead may coordinate with the SL reference WTRU and initiate a rediscovery of the SL reference WTRU.

[0156] Figure 4 This is a schematic diagram illustrating an exemplary SL positioning operation 400 in which a discovery failure occurs at the SL target WTRU, assisted by the SL positioning server WTRU.

[0157] like Figure 4 As shown in Figure 1, for example, via the SL client WTRU, the SL target WTRU can be triggered for location requests.

[0158] In section 2, the SL target WTRU can perform SL reference WTRU discovery and establish connections with discovered reference WTRUs.

[0159] Before proceeding with the location request, the SL target WTRU may determine whether one or more of the following conditions have occurred: (a) no SL reference WTRUs are found nearby; (b) one or more previously found SL reference WTRUs have moved away due to mobility; (c) it is experiencing congestion because it has served a sufficient number of client WTRUs; (d) it is unable to connect to the indicated SL reference WTRUs; and / or (e) based on the location request received from the SL client WTRU, some SL reference WTRUs / a subset of SL reference WTRUs have been found.

[0160] In 3a, if it is determined that any of events (a)-(d) (in 2) has occurred, the SL target WTRU may send a rejection message to the SL client WTRU with a reason code (e.g., "No SL reference WTRU", "Not enough SL reference WTRUs", "Cannot establish connection with SL reference WTRU", "Blocked", periodic timer in the case of retry and / or fallback time in the case of blockage).

[0161] WTRU1 can send a service acceptance message with a pending indication. The pending indication tells the SL location client WTRU that WTRU1 is querying the SL location server WTRU to see if location service is possible. WTRU1 can then perform 3b with the SL location server WTRU.

[0162] In 3b, if it is determined that event (e) (in 2) has occurred, the SL target WTRU may not directly send a rejection message. Instead, based on a default timer value, the SL target WTRU may perform X attempts at certain intervals. The number of attempts may be, for example, the number of rediscovery attempts until the target WTRU may have discovered a sufficient number of SL reference WTRUs. The number of attempts and / or rediscovery attempts may be capped and / or limited by a timer value (e.g., making attempts until the timer expires). The SL target WTRU may send SL location service information to the SL location server WTRU or SL location server for result inference, including a list of discovered reference WTRU IDs and their capabilities.

[0163] In section 4, based on positioning requirements, the SL positioning server WTRU can determine whether the SL target WTRU has discovered enough SL reference WTRUs. If the SL target WTRU has not discovered enough SL reference WTRUs, the SL positioning server WTRU can request rediscovery.

[0164] In step 5, the SL positioning server may request the SL target WTRU to perform the rediscovery of the SL reference WTRU (to find more SL reference WTRUs where possible), and / or may include the usual timer value.

[0165] A request to rediscover the SL target WTRU may include one or more of the following: a timer, one or more delay requirements, and / or a minimum number of SL reference WTRUs.

[0166] The timer can be a periodic timer that performs periodic attempts and an explicit maximum time under strict delay requirements, used to discover the SL reference WTRU until the expected number is reached.

[0167] Location latency requirements (one or more) may include a maximum tolerable latency, which ensures that for mission-critical services, location response does not take too long.

[0168] The minimum number of SL reference WTRUs can be associated with the expected service.

[0169] In step 6, the SL target WTRU can receive a rediscovery request from the SL location server.

[0170] The SL target WTRU can determine whether the request can be met (e.g., whether there is an explicit timer that requires more frequent rediscovery attempts or whether the delay requirement is too stringent), and can consider one or more power-saving requirements deployed by the SL target WTRU.

[0171] Alternatively, the target WTRU may initially meet the requirements, but no more SL reference WTRUs can be found and the maximum attempt / time has been reached.

[0172] In 7a, if any requirement of the rediscovery request (in 6) cannot be met, the SL target WTRU may send a rejection message to the SL client WTRU, for example, in response to the location request. The SL target WTRU may release the link with the SL client WTRU, and upon receiving the rejection message, the SL client WTRU may continue to discover another SL target WTRU for the location service request.

[0173] In 7b, if any requirement in the rediscovery request (in 6) cannot be met, the SL target WTRU may respond to the SL location server with a rejection message and / or an error stating the reason (e.g., "Power saving has been deployed", "Not enough SL reference WTRUs", etc.).

[0174] In SL location operation 400, the SL location server WTRU can be replaced by the LMF. Whether the location service is assisted by the LMF or the SL location server WTRU, the functionality remains the same; for example, the SL target WTRU (if a NAS connection exists – the default) sends location requests to the LMF. If no NAS connection exists, or if the LMF explicitly instructs the SL location server WTRU to be used instead of the LMF, the SL target WTRU sends location requests to the SL location server WTRU.

[0175] A procedure for rediscovering the SL reference WTRU used for SL server WTRU-assisted SL localization due to the failure of the target WTRU can be implemented.

[0176] Based on positioning requirements, the SL positioning server WTRU (or LMF) can determine whether the SL target WTRU has found enough SL reference WTRUs.

[0177] The SL location server WTRU (or LMF) can request rediscovery from the SL target WTRU to find more SL reference WTRUs. This request may include a timer, a delay requirement for location, and / or a minimum number of SL reference WTRUs for the intended service.

[0178] The SL location server WTRU (or LMF) can receive rejection messages stating a reason (e.g., "Power saving has been deployed", "Not enough SL reference UEs", etc.). In this case, the SL location server WTRU can release the link with the SL target WTRU and can send a configuration update to the SL client WTRU with another available SL target WTRU ID.

[0179] When the SL target WTRU cannot find any SL reference WTRU, cannot establish a connection with the SL reference WTRU, and / or cannot find one or more (e.g., all) SL reference WTRUs required by the SL location server and / or client WTRU, the SL target WTRU (WTRU1) can determine potential reasons for rejection.

[0180] The SL target WTRU (WTRU1) can send a rejection message to the SL client WTRU with a reason code (e.g., "No SL reference UE", "Not enough SL reference WTRUs", "Cannot establish a connection with the SL reference WTRU", "Blocking" and / or a periodic timer in the case of retry or a fallback time in the case of blocking).

[0181] The SL target WTRU (WTRU1) can send a service acceptance message with a pending indication. The pending indication tells the SL location client WTRU that WTRU1 is querying the SL location server WTRU to see if location service is possible.

[0182] The SL target WTRU (WTRU1) may not send rejection messages directly to the client WTRU. Instead, based on a default timer value and / or the configuration of the minimum number of reference WTRUs required for each service received from the LMF, the SL target WTRU (WTRU1) may perform a certain (e.g., predetermined) number of discovery attempts at regular intervals.

[0183] The SL target WTRU (WTRU1) can receive rediscovery requests from the SL location server and can determine whether the rediscovery request can be satisfied (e.g., the SL target WTRU is in a power-saving state and cannot perform frequent rediscovery attempts to meet the latency requirements, or the maximum attempts / time has been reached).

[0184] The SL target WTRU (WTRU1) can respond to the SL location server with a rejection message stating the reason (e.g., "Power saving has been deployed", "Not enough SL reference WTRUs", etc.).

[0185] The SL location server may be unable to assist SL location requests because it is overloaded (e.g., congestion; it may be too far away to meet the required location accuracy and latency; and / or it may be unavailable due to mobility).

[0186] Figure 5 This is a schematic diagram illustrating an exemplary SL location operation 500 assisted by the SL location server WTRU, in which a discovery failure occurs on the SL server WTRU.

[0187] like Figure 5 As shown in Figure 1, the SL target WTRU can be triggered for location requests (e.g., via the SL client WTRU).

[0188] In step 2, based on the NAS status (e.g., no NAS or with NAS), the SL target WTRU can determine whether to use the SL location server or LMF for SL location services.

[0189] In step 3, if the SL target WTRU has a NAS connection (within coverage), the LMF can instruct the target WTRU to send a location request to the SL location server WTRU, for example, instead of the LMF.

[0190] In step 4, the SL target WTRU can discover the SL location server WTRU and can send a location request to the SL location server WTRU.

[0191] In step 5, based on the received requests, the SL location server WTRU can determine its availability.

[0192] Although the SL positioning server WTRU has sufficient bandwidth to accommodate requests for any mission-critical service, if the SL positioning server WTRU cannot meet positioning requirements (e.g., latency and accuracy), then the SL positioning server WTRU can be deemed unavailable.

[0193] Although discoverable, if the SL location server WTRU cannot establish a connection due to congestion at the SL location server WTRU, the SL location server WTRU can determine that it is unavailable.

[0194] While the service has already been provided to the SL target WTRU, the SL location server WTRU can determine that the SL location server WTRU will be unavailable.

[0195] In 6a, if unavailable, the SL positioning server WTRU can send a rejection message to the SL target WTRU, stating an appropriate reason value as the reason for rejection (e.g., "SL positioning server UE unavailable", "SL positioning server cannot meet positioning requirements", "blocking", "cannot establish connection", etc.).

[0196] In 6b, the SL location server WTRU can provide the LMF with an unavailability indication and the target WTRU ID, so that the LMF can query for an alternative SL server WTRU located nearby. The SL location server WTRU can notify the LMF in advance, and / or as soon as an error condition is triggered, so that the LMF will not instruct other SL target WTRUs to select that server WTRU.

[0197] In 6c, if the target WTRU ID is included along with the unavailability indicator sent to the LMF (in 6b), the LMF may provide one or more alternative location server WRTU IDs to the SL target WTRU and / or to the SL location server WTRU, which are available in the vicinity of the target WTRU.

[0198] The LMF can provide any fallback or retry timers to the SL target WTRU. For example, the SL target WTRU can retry before it notifies the SL client WTRU that it cannot be discovered or that it cannot establish a connection with the SL location server WTRU. If the SL server WTRU has received any updates from the LMF, it can include one or more alternative SL location server WTRU IDs. For example, the target WTRU (WTRU1) can use that SL server WTRU for location services.

[0199] In 7, upon receiving a rejection message, the SL target WTRU may determine to: (a) wait for a given timer and continue retrying until the timer expires; (b) query another SL server WTRU (e.g., provided by the LMF or perform discovery again if the ID of an available server WTRU is unknown); and / or (c) send the location request to the LMF instead of the SL location server WTRU.

[0200] In step 8, based on the preceding determinations (in 7a, 7b, or 7c), the SL target WTRU may retry, find a new SL location server, and / or send a new location request to the LMF.

[0201] In step 9, if the selected SL server WTRU is unavailable after a retry and the selected SL server cannot find any other SL location server WTRU, the selected SL server WTRU can notify the SL client WTRU that the SL location server WTRU is unavailable.

[0202] Alternatively, if a NAS connection exists and the LMF initially instructs the SL target WTRU to switch to the SL location server WTRU for location services, then when the SL location server WTRU becomes unavailable, the SL target WTRU can send a notification to the LMF stating "SL location server WTRU is unavailable".

[0203] A procedure for rediscovering the SL reference WTRU, which is used for SL server WTRU-assisted SL localization, can be implemented in the event of a failure to locate the WTRU in the SL.

[0204] The SL positioning WTRU can receive positioning requests from the SL target WTRU.

[0205] The SL positioning WTRU can determine whether the SL positioning WTRU cannot meet positioning requirements (e.g., delay and accuracy), whether the SL positioning WTRU can establish a connection (e.g., whether it experiences congestion), and / or whether the SL positioning WTRU will soon become unavailable.

[0206] The SL positioning WTRU can send a rejection message to the SL target WTRU, indicating an appropriate reason value as the reason for rejection (e.g., "SL positioning server UE is unavailable", "SL positioning server cannot meet positioning requirements", "blocking", "cannot establish connection", etc.).

[0207] The SL can locate the WTRU and provide the LMF with an unavailable indication and / or the target WTRU ID, so that the LMF can query one or more alternative SL server WTRUs located nearby.

[0208] The SL-targeting WTRU can receive one or more alternative location server WTRU IDs from the LMF for the SL target WTRU, and the one or more alternative location server WTRU IDs can be included in the rejection message.

[0209] The SL target WTRU can provide backoff and / or retry timers to the SL target WTRU, so that the SL target WTRU can perform a retry before it notifies the SL client WTRU that the SL target WTRU cannot establish a connection with the location server.

[0210] The SL target WTRU can receive a rejection message from the SL positioning server WTRU, indicating an appropriate reason value as the reason for rejection (e.g., "SL positioning server UE is unavailable", "SL positioning server cannot meet positioning requirements", "blocking", "cannot establish connection", etc.).

[0211] The SL target WTRU can receive one or more alternative location server WTRU IDs and rejection reason codes from the LMF or SL location server.

[0212] Upon receiving a rejection message, the target SL WTRU can determine whether to wait for a given timer to expire and / or continue with a retry or query another SL server WTRU (e.g., using an ID provided by the LMF or by performing discovery again without knowing the ID of an available server WTRU).

[0213] The SL target WTRU can send a rejection message to the SL client WTRU, which has a reason code (e.g., "SL location server unavailable").

[0214] The SL target WTRU can send a location request message to the LMF indicating the reason "SL location server is unavailable", for example, so that the LMF can take over the location service.

[0215] LMF can provide one or more alternative location server WTRU IDs to the SL target WTRU and / or the SL location server WTRU.

Claims

1. A first wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: The sidelink SL location service request from the second WTRU is rejected. Based on the determination to reject the SL location service request, a service acceptance message is sent to the second WTRU, wherein the service acceptance message includes a pending indication, that is, the first WTRU will determine whether the server WTRU can assist the SL location service request; Send the SL location service information to the server WTRU; In response to the SL location service information, a rediscovery request is received from the server WTRU; It was determined that the rediscovery request was unsuccessful; and A first rejection message is sent to the second WTRU, the first rejection message including one or more of a first cause code, a periodic timer, or a rollback time indicating the reason associated with the first rejection message.

2. The first WTRU as claimed in claim 1, wherein the processor is configured to determine whether to reject the SL location service request from the second WTRU based on one or more of the following: It is determined that the SL reference WTRU is not near the first WTRU; It was determined that the previously identified SL reference WTRU was no longer near the first WTRU; The congestion experienced by the first WTRU on the SL resource; or It has been determined that a connection failure with the SL reference WTRU has occurred.

3. The first WTRU as claimed in claim 1 or 2, wherein the first cause code includes one or more of the following: There is no indication that the SL reference WTRU is located near the first WTRU; There is insufficient SL reference WTRU to indicate that it is located near the first WTRU; The first WTRU is experiencing congestion on the SL resource; or The first WTRU cannot establish a connection with the SL reference WTRU.

4. The first WTRU as claimed in any one of claims 1 to 3, wherein the processor is configured to: In response to determining that the rediscovery request was unsuccessful, a second rejection message is sent to the server WTRU, the second rejection message including a second reason code associated with the rediscovery request.

5. The first WTRU as claimed in claim 4, wherein the second cause code includes an indication that the SL reference WTRU has deployed power-saving technology or an indication that not enough SL reference WTRUs are found near the first WTRU.

6. The first WTRU as claimed in any one of claims 1 to 5, wherein the processor is configured to determine that the rediscovery request is unsuccessful based on a delay requirement, a power-saving mode of the first WTRU, or for identifying the number of rediscovery attempts of one or more SL reference WTRUs, wherein the number of rediscovery attempts is based on a timer value.

7. The first WTRU as claimed in any one of claims 1 to 6, wherein the processor is configured to: Receive SL location service request from the second WTRU.

8. The first WTRU as claimed in any one of claims 1 to 7, wherein the processor is configured to: Based on the SL location service request, one or more reference WTRUs are discovered.

9. The first WTRU as claimed in any one of claims 1 to 8, wherein the processor is configured to: Based on the determination to reject the SL location service request, a subset of the SL reference WTRU is found; and Based on the timer value, it was determined that the rediscovery request was unsuccessful.

10. The first WTRU of claim 8, wherein the processor is configured to: Based on the determination that the rediscovery request was unsuccessful according to the timer value, SL location service information is sent to the server WTRU for result inference, wherein the result inference includes a list of identifiers associated with the subset of the SL reference WTRU or a list of capabilities associated with the subset of the SL reference WTRU.

11. A method performed by a first wireless transmit / receive unit (WTRU), the method comprising: The sidelink SL location service request from the second WTRU is rejected. Based on the determination to reject the SL location service request, a service acceptance message is sent to the second WTRU, wherein the service acceptance message includes a pending indication, that is, the first WTRU will determine whether the server WTRU can assist the SL location service request; Send the SL location service information to the server WTRU; In response to the SL location service information, a rediscovery request is received from the server WTRU; It was determined that the rediscovery request was unsuccessful; and A first rejection message is sent to the second WTRU, the first rejection message including one or more of a first cause code, a periodic timer, or a rollback time indicating the reason associated with the first rejection message.

12. The method of claim 11, wherein the method includes determining to reject the SL location service request from the second WTRU based on one or more of the following: It is determined that the SL reference WTRU is not near the first WTRU; It was determined that the previously identified SL reference WTRU was no longer near the first WTRU; The congestion experienced by the first WTRU on the SL resource; or It has been determined that a connection failure with the SL reference WTRU has occurred.

13. The method of claim 11 or 12, wherein the first reason code includes one or more of the following: There is no indication that the SL reference WTRU is located near the first WTRU; There is insufficient SL reference WTRU to indicate that it is located near the first WTRU; The first WTRU is experiencing congestion on the SL resource; or The first WTRU cannot establish a connection with the SL reference WTRU.

14. The method of any one of claims 11 to 13, wherein the method comprises: In response to determining that the rediscovery request was unsuccessful, a second rejection message is sent to the server WTRU, the second rejection message including a second reason code associated with the rediscovery request.

15. The method of claim 14, wherein the second cause code includes an indication that the SL reference WTRU has deployed power-saving technology or an indication that not enough SL reference WTRUs are found near the first WTRU.

16. The method of any one of claims 11-15, wherein the method includes determining that the rediscovery request was unsuccessful based on a delay requirement, a power-saving mode of the first WTRU, or a number of rediscovery attempts for identifying one or more SL reference WTRUs, wherein the number of rediscovery attempts is based on a timer value.

17. The method of any one of claims 11-16, wherein the method comprises: Receive SL location service request from the second WTRU.

18. The method of any one of claims 11-17, wherein the method comprises: Based on the SL location service request, one or more reference WTRUs are discovered.

19. The method of any one of claims 11-18, wherein the method comprises: Based on the determination to reject the SL location service request, a subset of the SL reference WTRU is found; and Based on the timer value, it was determined that the rediscovery request was unsuccessful.

20. A first wireless transmit / receive unit (WTRU), comprising: The processor is configured as follows: Receive a discovery request from the second WTRU, wherein the second WTRU is the side link client WTRU; Based on the discovery request, initiate one or more side-link reference WTRU discovery procedures; Based on the discovery procedure, it is determined that the discovery request was unsuccessful; and A rejection message is sent to the second WTRU, the rejection message including a reason code, a periodic timer, or a rollback time indicating the reason associated with the rejection message.

Images