Method and apparatus for enabling sidelink positioning for location of out-of-coverage wireless transmit / receive units

Abstract

A wireless transmit / receive unit (WTRU) may be configured to receive a sidelink (SL) positioning request from another WTRU. The first SL positioning request may include security information. The security information may be used to validate the SL positioning request. The WTRU may be configured to transmit an SL positioning response to the other WTRU. The SL positioning response may be transmitted based on verification of the SL positioning request using at least the security information. The security information may be received in a secure container. The WTRU may be configured to perform SL positioning with the other WTRU.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 393,307, filed on July 29, 2022, the entire contents of which are incorporated herein by reference. Background Art

[0003] Current mobile Internet applications use user location information for various services such as navigation, customized content provisioning, and traffic optimization for ultra-high-quality video streaming, etc. It is expected that more applications will utilize user location information and may be applicable to applications such as drones, unmanned aerial vehicles (UAVs), vehicle-to-everything (V2X), and extended reality (XR).

[0004] In current fifth generation (5G) systems, location information of wireless transmit / receive units (WTRUs), also referred to as user equipment (UEs), can be supported by various network technologies. However, these approaches do not address WTRUs that are not within network coverage (referred to as out-of-coverage). Summary of the invention

[0005] Wireless communications between one or more user equipment (UE) and a network are considered herein. UE may also be referred to as a wireless transmit / receive unit (WTRU). The terms "UE" and "WTRU" are used interchangeably herein. Methods and apparatus for determining the location of a WTRU outside a network (e.g., also referred to herein as out of coverage) are described herein. In an example embodiment, side link (SL) positioning is utilized between a WTRU in a network and another WRTU that is not in the network. SL positioning may be accomplished via a PC5 interface between these WRTUs. In various example embodiments, a secure container may be used for security and authentication purposes. A request for the location of an out-of-coverage WRTU may be initiated by another WRTU, a network entity (e.g., AMF, LMF, etc.), and / or an application (e.g., AF, LCS), etc.

[0006] A first WTRU (e.g., a target WTRU) may be configured to receive a SL positioning request from a second WTRU (e.g., a positioned WTRU). The first SL positioning request may include security information. The security information may be used to verify the SL positioning request. The first WTRU (e.g., a target WTRU) may be configured to transmit a SL positioning response to the second WTRU (e.g., a positioned WTRU). The SL positioning response may be transmitted based on, for example, verification of the SL positioning request using at least the security information. The first WTRU (e.g., a target WTRU) may be configured to perform SL positioning with the second WTRU (e.g., a positioned WTRU). Performing SL positioning with the second WTRU (e.g., a positioned WTRU) may include: receiving an indication of one or more distance measurements or direction measurements associated with the second WTRU (e.g., a positioned WTRU). Additionally or alternatively, performing SL positioning with the second WTRU (e.g., a positioned WTRU) may include: determining an indication of one or more distance measurements or direction measurements associated with the second WTRU (e.g., a positioned WTRU).

[0007] The first WTRU (e.g., a target WTRU) may be configured to receive configuration information. The configuration information may include one or more parameters, such as to derive security credentials for verifying the security information in the SL positioning request. The security information may be received in a secure container. The secure container may be protected by, for example, security credentials derived from the one or more parameters received in the configuration information.

[0008] The first WTRU (e.g., the target WTRU) may be configured to verify the validity of the SL positioning request, for example, by verifying the security information received in the secure container. The first WTRU (e.g., the target WTRU) may be configured to perform discovery with the second WTRU (e.g., the located WTRU), for example, based on receiving a (e.g., second) SL positioning request from the network. The security information may include one or more of the following: application function (AF) ID, location service (LCS) client information, location information request for the first WTRU (e.g., the target WTRU), service type, second WTRU list, quality of service (QoS) information and / or type of location request. The SL positioning request may include, for example, a list of second WTRUs (e.g., located WTRUs) in a secure container. The verification of the SL positioning request may be based on one or more of the following: the security information and / or the second WTRU (e.g., located WTRU) in the list of the second WTRU (e.g., located WTRU). The first WTRU (e.g., the target WTRU) may be configured to initiate a mobile originated location request (MO-LR). The MO-LR may be based on the second WTRU (eg, located WTRU) being in the second WTRU (eg, located WTRU) list. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding can be obtained from the following detailed description, which is given by way of example in conjunction with its accompanying drawings. As with the detailed description, the figures in such drawings are examples. Therefore, the drawings and specific embodiments should not be considered limiting, and other equally effective examples are possible and intended. The same reference numerals represent the same elements in the drawings.

[0010] Figure 1A is an example system diagram illustrating an example communication system in which one or more disclosed embodiments may be implemented.

[0011] Figure 1B is an example of a method that can be used according to an embodiment of the present invention. Figure 1A An example system diagram of an example wireless transmit / receive unit (WTRU) for use within an example communication system.

[0012] Figure 1C is an example of a method that can be used according to an embodiment of the present invention. Figure 1A An example system diagram of an example Radio Access Network (RAN) and an example Core Network (CN) used within the illustrated communication system.

[0013] Figure 1D is an example of an embodiment in which Figure 1A An example system diagram of another example RAN and another example CN for use within the illustrated communication system.

[0014] Figure 2 Depicted is an example architecture of a 5G or next generation network.

[0015] Figure 3 Depicted is an example 5G / next generation network that includes location services.

[0016] Figure 4 An example procedure for a Mobile Terminated Location Request (MT-LR) for a target out of coverage WTRU is depicted.

[0017] Figure 5 is an example procedure for MT-LR using sidelink (SL) positioning signaling with a secure container.

[0018] Fig. 6A and Figure 6B An example procedure for a Mobile Originated Location Request (MO-LR) for a target out of coverage WTRU is depicted.

[0019] Figure 7 An example procedure for an MT-LR to a target WTRU using an existing connection with a located WTRU is depicted. DETAILED DESCRIPTION

[0020] Figure 1A 1 is a diagram illustrating an example communication system 100 in which one or more disclosed embodiments may be implemented. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, broadcast, etc. to multiple wireless users. The communication system 100 may enable multiple wireless users to access such content through sharing of 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 OFDM (ZT UW DTS-s OFDM), unique word OFDM (UW-OFDM), resource block filtered OFDM, filter bank multi-carrier (FBMC), etc.

[0021] like Figure 1AAs shown, the communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, Internet 110 and other networks 112, but it should 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, 102d may be any type of device configured to operate and / or communicate in a wireless environment. By way of example, the WTRUs 102a, 102b, 102c, 102d (any of which may be referred to as a “station” and / or “STA”) may be configured to send and / or receive wireless signals and may include user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a subscription-based unit, a pager, a cellular phone, a personal digital assistant (PDA), a smart phone, a laptop, a netbook, a personal computer, a wireless sensor, a hotspot or Mi-Fi device, an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in an industrial and / or automated process chain environment), a consumer electronic device, a device operating on a commercial and / or industrial wireless network, etc. Any of the WTRUs 102a, 102b, 102c, and 102d may be interchangeably referred to as a UE.

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

[0023] 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 (BSC), radio network controllers (RNC), relay nodes, etc. Base station 114a and / or base station 114b may be configured to send and / or receive wireless signals on one or more carrier frequencies (which may be referred to as cells (not shown)). These frequencies may be in a licensed spectrum, an unlicensed spectrum, or a combination of a licensed spectrum and an unlicensed spectrum. A cell may provide coverage of wireless services to 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, a 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 an embodiment, base station 114a may employ multiple-input multiple-output (MIMO) technology and may utilize multiple transceivers for each sector of the cell. For example, beamforming may be used to send and / or receive signals in a desired spatial direction.

[0024] The base stations 114a, 114b may communicate with one or more of the WTRUs 102a, 102b, 102c, 102d over an air interface 116, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, centimeter wave, micrometer wave, infrared (IR), ultraviolet (UV), visible light, etc.). The air interface 116 may be established using any suitable radio access technology (RAT).

[0025] More specifically, as noted above, the communication system 100 may be a multiple access system and may employ one or more channel access schemes such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a in the RAN 104 / 113 and the WTRUs 102a, 102b, 102c may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), which may use Wideband CDMA (WCDMA) to establish the air interface 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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0042] The processor 118 may also be coupled to other peripherals 138, which may include one or more software modules and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include an accelerometer, an electronic compass, a satellite transceiver, a digital camera (for photos and / or video), a universal serial bus (USB) port, a vibration device, a television transceiver, a hands-free headset, module, a frequency modulation (FM) radio unit, a digital music player, a media player, a video game player module, an Internet browser, a virtual reality and / or augmented reality (VR / AR) device, an activity tracker, etc. Peripheral device 138 may include one or more sensors, which may be one or more of the following: a gyroscope, an accelerometer, a Hall effect sensor, a magnetometer, an orientation sensor, a proximity sensor, a temperature sensor, a time sensor; a geolocation sensor; an altimeter, a light sensor, a touch sensor, a magnetometer, a barometer, a gesture sensor, a biometric sensor, and / or a humidity sensor.

[0043] The WTRU 102 may include a full-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes used for 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 for reducing and / or substantially eliminating self-interference via signal processing performed via hardware (e.g., a choke) or via a processor (e.g., a separate processor (not shown) or via processor 118). In an embodiment, the WRTU 102 may include a half-duplex radio for which transmission and reception of some or all of the signals (e.g., associated with particular subframes used for UL (e.g., for transmission) or downlink (e.g., for reception)) may be concurrent and / or simultaneous.

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

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

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

[0047] Figure 1C The illustrated CN 106 may include a mobility management entity (MME) 162, a serving gateway (SGW) 164, and a packet data network (PDN) gateway (or PGW) 166. While each of the foregoing elements is depicted as being part of the CN 106, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

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

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

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

[0051] The CN 106 may facilitate communications with other networks. For example, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices. For example, the CN 106 may include, or may be in communication with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the CN 106 and the PSTN 108. In addition, the CN 106 may provide the WTRUs 102a, 102b, 102c with access to other networks 112, which may include other wired networks and / or wireless networks owned and / or operated by other service providers.

[0052] Although the WTRU Figures 1A to 1D Although described as wireless terminals, it is contemplated that in certain representative embodiments, such terminals may (eg, temporarily or permanently) use a wired communications interface with a communications network.

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

[0054] A WLAN in infrastructure basic service set (BSS) mode may have an access point (AP) for the BSS and one or more stations (STA) associated with the AP. The AP may have access or an interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or out of the BSS. Traffic originating from outside the BSS and directed to the STA may be reached by the AP and may be delivered to the STA. Traffic originating from the STA and directed to a destination outside the BSS may be transmitted to the AP to be delivered to the corresponding destination. Traffic between STAs within the BSS may be transmitted by the AP, for example, wherein the source STA may transmit traffic to the AP, and the AP may deliver traffic to the destination STA. Traffic between STAs within the BSS may be considered and / or referred to as point-to-point traffic. Direct link establishment (DLS) may be utilized to transmit point-to-point traffic between the source STA and the destination STA (e.g., directly between them). In certain representative embodiments, the DLS may use 802.11e DLS or 802.11z tunnel DLS (TDLS). A WLAN using an independent BSS (IBSS) mode may not have an AP, and STAs within or using the IBSS (eg, all STAs in the STA) may communicate directly with each other. The IBSS communication mode may sometimes be referred to herein as an "ad hoc" communication mode.

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

[0056] High throughput (HT) STAs may communicate using a 40 MHz wide channel, for example, via a combination of a primary 20 MHz channel and adjacent or non-adjacent 20 MHz channels to form a 40 MHz wide channel.

[0057] Very high throughput (VHT) STA can support 20MHz, 40MHz, 80MHz and / or 160MHz wide channels. 40MHz channels and / or 80MHz channels can be formed by combining continuous 20MHz channels. 160MHz channels can be formed by combining 8 continuous 20MHz channels, or by combining two non-continuous 80MHz channels (this can be called 80+80 configuration). For 80+80 configuration, after channel coding, the data can pass through a segment parser that can divide the data into two streams. Each stream can be processed by inverse fast Fourier transform (IFFT) and time domain processing separately. These streams can be mapped to two 80MHz channels, and data can be sent by the transmitter STA. At the receiver of the receiver STA, the above-mentioned operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the medium access control (MAC).

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

[0059] WLAN systems that can support multiple channels and channel bandwidths (such as 802.11n, 802.11ac, 802.11af, and 802.11ah) include channels that can be designated as primary channels. The primary channel may have a bandwidth equal to the maximum common operating bandwidth supported by all STAs in the BSS. The bandwidth of the primary channel may be set and / or limited by a STA (which supports the minimum bandwidth operating mode) from all STAs operating in the BSS. In the example of 802.11ah, for STAs (e.g., MTC-type devices) that support (e.g., only support) a 1MHz mode, the primary channel may be 1MHz wide, even if the AP and other STAs in the BSS support 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidth operating modes. Carrier sensing and / or network allocation vector (NAV) settings may depend on the state of the primary channel. If the primary channel is busy, for example, because a STA (supporting only a 1MHz operating mode) is sending to the AP, the entire available band may be considered busy even if most of the band remains idle and may be available.

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

[0061] Figure 1D 1 is a system diagram illustrating the RAN 113 and the CN 115 in accordance with an embodiment. As noted above, the RAN 113 may employ NR radio technology to communicate with the WTRUs 102a, 102b, 102c over the air interface 116. The RAN 113 may also be in communication with the CN 115.

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

[0063] The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using transmissions associated with parameter sets that may be scalable. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary for different transmissions, different cells, and / or different portions of the wireless transmission spectrum. The WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., containing different numbers of OFDM symbols and / or continuously varying absolute time lengths).

[0064] The gNBs 180a, 180b, 180c may be configured to communicate with the WTRUs 102a, 102b, 102c in a standalone configuration and / or a non-standalone configuration. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c while not accessing other RANs (e.g., such as the eNodeBs 160a, 160b, 160c). In a standalone configuration, the WTRUs 102a, 102b, 102c may use one or more of the gNBs 180a, 180b, 180c as mobility anchors. In a standalone configuration, the WTRUs 102a, 102b, 102c may communicate with the gNBs 180a, 180b, 180c using signals in an unlicensed band. In a non-standalone configuration, the WTRUs 102a, 102b, 102c may communicate / connect with the gNB 180a, 180b, 180c while also communicating / connecting with another RAN, such as the eNode-B 160a, 160b, 160c. For example, the WTRUs 102a, 102b, 102c may implement the DC principle to communicate with one or more gNBs 180a, 180b, 180c and one or more eNode-Bs 160a, 160b, 160c substantially simultaneously. In a non-standalone configuration, the eNode-B 160a, 160b, 160c may act as a mobility anchor for the WTRUs 102a, 102b, 102c, and the gNB 180a, 180b, 180c may provide additional coverage and / or throughput for serving the WTRUs 102a, 102b, 102c.

[0065] Each of the gNBs 180a, 180b, 180c may be associated with a specific cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in UL and / or DL, support of network slicing, dual connectivity, interworking between NR and E-UTRA, routing of user plane data towards a user plane function (UPF) 184a, 184b, routing of control plane information towards an access and mobility management function (AMF) 182a, 182b, etc. Figure 1D As shown, gNBs 180a, 180b, and 180c may communicate with each other via an Xn interface.

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

[0067] The AMF 182a, 182b may be connected to one or more of the gNBs 180a, 180b, 180c in the RAN 113 via the N2 interface and may act as a control node. For example, the AMF 182a, 182b may be responsible for authenticating users of the WTRU 102a, 102b, 102c, support of network slicing (e.g., handling of different PDU sessions with different requirements), selecting a specific SMF 183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. The AMF 182a, 182b may use network slicing in order to customize CN support for the WTRU 102a, 102b, 102c based on the type of services utilized by the WTRU 102a, 102b, 102c. For example, different network slices may be established for different use cases, such as services relying on ultra-reliable low latency (URLLC) access, services relying on enhanced mobile broadband (eMBB) access, and / or services for machine type communication (MTC) access, etc. The AMF 162 may provide a control plane function for switching between the RAN 113 and other RANs (not shown) that employ other radio technologies, such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP (3rd Generation Partnership Project) access technologies, such as WiFi.

[0068] The SMF 183a, 183b may be connected to the AMF 182a, 182b in the CN 115 via the N11 interface. The SMF 183a, 183b may also be connected to the UPF 184a, 184b in the CN 115 via the N4 interface. The SMF 183a, 183b may select and control the UPF 184a, 184b, and configure the traffic routing through the UPF 184a, 184b. The SMF 183a, 183b may perform other functions, such as managing and allocating UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, providing downlink data notification, etc. The PDU session type may be IP-based, non-IP-based, Ethernet-based, etc.

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

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

[0071] Given that Figures 1A to 1D as well as Figures 1A to 1D Corresponding to the description of the present invention, one or more or all of the functions described herein with respect to one or more of the following items may be performed by one or more simulation devices (not shown): WTRU 102a-102d, base station 114a-114b, evolved Node B 160a-160c, MME 162, SGW 164, PGW 166, gNB 180a-180c, AMF 182a-182b, UPF 184a-184b, SMF 183a-183b, DN 185a-185b and / or any other device described herein. The simulation device may be one or more devices configured to mimic one or more or all of the functions described herein. For example, the simulation device may be used to test other devices and / or simulate network and / or WTRU functions.

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

[0073] One or more simulation devices can perform one or more (including all) functions without being implemented / deployed as part of a wired and / or wireless communication network. For example, the simulation device can be used in a test scenario in a test laboratory and / or a non-deployed (e.g., testing) wired and / or wireless communication network to implement testing of one or more components. One or more simulation devices can be test equipment. Direct RF coupling and / or wireless communication via an RF circuit system (e.g., which can include one or more antennas) can be used by the simulation device to send and / or receive data.

[0074] Methods and apparatus are described herein for facilitating location-based services for WTRUs that may not be covered by a network (eg, out of coverage). In the examples described herein, a sidelink (SL) technique may be used to determine the location of the WTRU.

[0075] A WTRU (e.g., a target WTRU) may be configured to receive a SL positioning request from another WTRU (e.g., a positioned WTRU). The first SL positioning request may include security information. The security information may be used to verify the SL positioning request. The WTRU (e.g., a target WTRU) may be configured to transmit a SL positioning response to the other WTRU (e.g., a positioned WTRU). The SL positioning response may be transmitted based on, for example, verification of the SL positioning request using at least the security information. The WTRU (e.g., a positioned or target WTRU) may be configured to perform SL positioning with the other WTRU (e.g., a positioned or target WTRU). Performing SL positioning with the other WTRU (e.g., a positioned or target WTRU) may include: receiving an indication of one or more distance measurements or direction measurements associated with the other WTRU (e.g., a positioned or target WTRU). Additionally or alternatively, performing SL positioning with the second WTRU may include: determining one or more distance measurements or direction measurements associated with the other (e.g., positioned or target) WTRU.

[0076] The WTRU (e.g., a target WTRU) may be configured to receive configuration information. The configuration information may include one or more parameters, for example, to derive security credentials for verifying the security information in the SL positioning request. The security information may be received in a secure container. The secure container may be protected by, for example, security credentials derived from the one or more parameters received in the configuration information.

[0077] The WTRU (e.g., the target WTRU) may be configured to verify the validity of the SL positioning request, for example, by verifying the security information received in the secure container. The WTRU (e.g., the target WTRU) may be configured to perform discovery with the other WTRU (e.g., the located WTRU), for example, based on receiving a (e.g., second) SL positioning request from the network. The security information may include one or more of the following: application function (AF) ID, location service (LCS) client information, location information request for the WTRU (e.g., the target WTRU), service type, second WTRU list, quality of service (QoS) information and / or type of location request. The SL positioning request may include, for example, a list of WTRUs (e.g., located WTRUs) in a secure container. The verification of the SL positioning request may be based on one or more of the following: the security information and / or the other WTRU (e.g., located WTRU) in the list of the WTRU (e.g., located WTRU). The WTRU (e.g., the target WTRU) may be configured to initiate a mobile originated location request (MO-LR). The MO-LR may be based on the other WTRU (eg, located WTRU) being in the list of WTRUs (eg, located WTRUs).

[0078] Figure 2 An example architecture of a fifth generation (5G) or next generation (NextGen) network 200 is depicted. Figure 2 As depicted, access network 202 (e.g., radio access network (RAN)) refers to a 5G radio access technology (RAT) or an evolved universal mobile telecommunications system (UMTS) terrestrial radio access (E-UTRA), which may, for example, be connected to a next generation core network.

[0079] The access control and mobility management function (AMF) 204 may include one or more of registration management, connection management, reachability management, or mobility management, etc. The session management function (SMF) 206 may include one or more of session management, WTRU IP address allocation, or selection and control of user plane (UP) function (UPF) 208, etc. Session management may include session establishment and / or modification and release. The user plane function (UPF) 208 may include one or more of packet routing and forwarding, packet inspection, or traffic usage reporting, etc.

[0080] One or more 5G location services may be configured to transmit positioning information of the WTRU 220. The positioning of the WTRU 220 may be supported by a RAT-related positioning method. The RAT-related positioning method may rely on one or more measurements of 3GPP RAT measurements obtained by the target WTRU 220 and / or measurements of 3GPP RAT signals obtained by the access network (e.g., sent by the target WTRU 220). The positioning of the WTRU 220 may be supported by a RAT-independent positioning method. The RAT-independent positioning method may rely on non-RAT measurements and / or other information obtained by the WTRU 220. The location information of one or more target WTRUs 220 may be requested and / or reported. For example, the location information of one or more target WTRUs 220 may be requested by one or more of a location service (LCS) client, an application function (AF) 210 inside or outside a 3GPP operator network, or a control plane network function (NF) inside a 3GPP system and / or the location information may be reported to one or more of the above. For a location request from the LCS client and / or the AF 210, a privacy check on the target WTRU 220 may be enabled, for example, to check whether it is allowed to obtain the location information of the WTRU 220.

[0081] Figure 3 An example 5G / next generation network 300 including location services is depicted. Figure 3As depicted, AN 302 (e.g., RAN) may represent one or more of a next generation RAN (NG-RAN), a trusted non-3GPP access, or an untrusted non-3GPP access. The access network may be configured to process one or more positioning procedures. These positioning procedures may include one or more of: locating a target WTRU 304, transmitting location-related information not associated with a specific target WTRU 304, or passing positioning messages between an access control and mobility management function (AMF) 306 or a location management function (LMF) 308 and the target WTRU 304, etc. The AF 310 and / or NF may access the LCS from, for example, a gateway mobile location center (GMLC) 314 in the same 3GPP operator network. The LCS client 312 may access the LCS from the GMLC 314. The external AF 310 may access the LCS from a network open function (NEF) 316. The GMLC 314 may be configured to handle one or more of the following: a request from an external LCS client 312; an AF via the NEF 316 in the case where the AF is an external AF; or forwarding a location request to an appropriate NF. A location retrieval function (LRF) 318 may be configured to retrieve or verify location information. The LRF 318 may be co-located with the GMLC 314 or separate from the GMLC 314. The LMF 308 may manage (e.g., overall) coordination and / or scheduling of resources (e.g., required resources) for locating the WTRU 304 registered with or accessing the 5GCN. The LMF 308 may calculate and / or verify (e.g., final) location-related information and / or (e.g., achieved) accuracy. One or more of the LMF 308, the LRF 318, and the GMLC 314 may be included as a network function of the 5CGN.

[0082] One or more types of location requests may be supported. For example, mobile terminated location requests (MT-LR) may be supported. Using MT-LR, the LCS client and / or AF may transmit a location request, such as for the location of a target WTRU, to the 5G network. Mobile originated location requests (MO-LR) may be supported. Using MO-LR, the WTRU may transmit a request, such as for location-related information of the WTRU, to the 5G network. Immediate location requests may be supported. Using immediate location requests, the LCS client and / or AF may transmit or initiate a location request for a target WTRU and / or receive a response containing the location information of the target WTRU within a short period of time. Immediate location requests may be used, for example, for MT-LR and / or MO-LR. Delayed location requests may be supported. Using delayed location requests, the LCS client and / or AF may transmit a location request for a target WTRU to the 5G network and / or receive a response, such as when an indication event for the target WTRU occurs at some future time. Delayed location requests may be used for MT-LR.

[0083] Sidelink (SL) positioning may refer to positioning via a PC5 interface. Ranging may refer to determining the distance between two or more WTRUs and / or the direction and / or relative positioning of one WTRU to another WTRU. Ranging-based services and / or SL positioning may include one or more of distance measurements or direction measurements. A WTRU may request distance measurements and / or direction measurements. A WTRU with ranging and / or SL positioning capabilities may have proximity services (ProSe) and / or vehicle-to-everything (V2X) capabilities. A reference WTRU may refer to a WTRU configured to determine a reference plane and / or reference direction in ranging-based services and / or SL positioning. A target WTRU may refer to a WTRU whose distance, direction and / or positioning is measured in a ranging-based service and / or SL positioning compared to a reference plane, reference direction and / or position of a reference WTRU (e.g., a positioned WTRU). A WTRU participating in ranging and / or sidelink positioning may be both a target WTRU and a reference WTRU, and / or may switch roles in the same ranging and / or SL positioning session. A positioned WTRU may refer to a WTRU whose location is known or is capable of knowing its location, for example using a user-to-user (Uu) based positioning 5G system. A positioned WTRU may be used to determine the location of another WTRU using sidelink positioning. An assisted WTRU may refer to a WTRU that can provide assistance for ranging and / or SL positioning, for example when direct ranging and / or SL positioning between a reference WTRU and a target WTRU is not supported.

[0084] The location information of the WTRU may be supported by a radio access technology (RAT)-dependent method and / or a RAT-independent method. The RAT-dependent method may rely on the interaction between the WTRU and the 5G system. The RAT-independent method may rely on information transmitted from the WTRU.

[0085] Methods and apparatus for providing WTRU location services, for example, when the WTRU is out of coverage, are described herein. These location services may be applicable, for example, to 5G location services (such as MT-LR and / or MO-LR). In order to protect user privacy, the WTRU may determine whether the location request comes from a legitimate and / or authorized entity. The 5G location service may authorize a location request from an AF and / or LCS client based on checking the privacy profile of the WTRU for location services in a unified data management function (UDM). If the WTRU is trusted by the 5G core network (5GCN) and / or if the WTRU receives a location request from the 5G system, the WTRU may execute the procedures following the request. When the WTRU is out of coverage and the AF and / or LCS client requests the location information of the WTRU, the request may be relayed by another WTRU. Even if the WTRU and the other WTRU do not have a trust relationship, the WTRU may verify the location request from the other WTRU. For example, when the first WTRU is out of coverage, the first WTRU may verify the location request from the second WTRU. Location services may be used for one or more applications, such as for law enforcement operations and / or emergency services. When the WTRU is out of coverage, the WTRU may ignore the location request, for example, regardless of the application of the location request. The WTRU may be aware of the application from which the location request is requested, and / or the WTRU may respond to the request. For example, the WTRU may respond to the request based on the application from which the location request is requested.

[0086] Methods and apparatus are described herein with respect to a WTRU supporting a PC5 interface. The PC5 interface may be supported by a ProSe layer in the WTRU. Additionally or alternatively, other suitable interfaces may be utilized. The methods and apparatus may include the WTRU being configured for ranging and / or SL positioning.

[0087] The network (e.g., 5GCN) may perform one or more of the following operations: select a located WTRU for sidelink positioning with a target WTRU; start the located WTRU to discover the target WTRU; and trigger the located WTRU to perform sidelink positioning with the target WTRU. For example, when there is a location request from the AF and / or LCS client for a target WTRU that is authorized to perform SL positioning and / or ranging and the 5GCN knows that the target WTRU is out of coverage, the network (e.g., 5GCN) may perform one or more of the following operations: select a located WTRU for sidelink positioning with the target WTRU; start the located WTRU to discover the target WTRU; and / or trigger the located WTRU to perform sidelink positioning with the target WTRU. The network (e.g., 5GCN) may maintain a list of located WTRUs within the potential coverage of the target WTRU for each target WTRU. For example, a network (e.g., 5GCN) may maintain a list of located WTRUs within the potential coverage of the target WTRU for each target WTRU based on the last known location of the target WTRU, with or without using analysis information about the mobility of the target WTRU and / or the location of the located WTRUs.

[0088] A network (e.g., 5GCN) may include a security container in a request message, for example, in response to a network (e.g., 5GCN) request to perform sidelink positioning with a target WTRU for a positioned WTRU. The security container may be forwarded to the target WTRU, and / or the target WTRU may, for example, use the information included in the security container to verify the sidelink positioning request from the positioned WTRU. The information in the security container may be protected by one or more security credentials. For example, the information in the security container may be protected by one or more security credentials shared by the network (e.g., 5GCN) and the target WTRU. A NF configured to handle sidelink positioning may, for example, transmit a request to an authentication server function (AUSF) for protecting the sidelink positioning request using a shared key between the AUSF and the target WTRU. Additionally or alternatively, a NF configured to handle sidelink positioning may transmit a request to an authentication server function (AUSF) for protecting the sidelink positioning request upon receiving an LCS client or AF location request. The NF may securely bind the sidelink positioning request to one or more target and / or positioned WTRU identities. The NF may determine the (e.g., last) serving AUSF, for example, by querying a unified data management function (UDM). The NF may receive a protected sidelink positioning request from the AUSF. The NF may forward the protected sidelink positioning request to the target WTRU, for example, via a located WTRU (e.g., during a discovery procedure or a sidelink positioning request). The secure container may contain a protected authorization token from the AF, which may be forwarded (e.g., transparently) to the target WTRU by the network (e.g., 5GCN) and / or verified by a SL positioning application on the target WTRU.

[0089] The target WTRU may advertise its capabilities during registration and / or the target WTRU may be provided with parameters for SL positioning, for example when the target WTRU is configured for SL positioning. Additionally or alternatively, the target WTRU may transmit an indication indicating that the target WTRU can perform SL positioning, for example when the WTRU is out of coverage. The target WTRU may be provided with parameters for SL positioning (when out of coverage), for example. These parameters may include one or more of the following: target WTRU ID information (e.g., for discovery), PC5 link establishment (e.g., for SL positioning applications), ProSe service information (e.g., for SL positioning applications), security credentials, or parameters for deriving security credentials. The parameters for deriving security credentials can be used to verify and / or decrypt a secure container for location service requests from 5GCN. For example, during the registration phase, the WTRU may be provided with a list of located WTRU ID information.

[0090] The WTRU may be provided with a list of located WTRUs, such as a list of located WTRUs installed and / or maintained by an operator or any authorized authority. The list of located WTRUs may be in priority order. One or more located WTRUs in the list of located WTRUs may have location information known in the network. Additionally or alternatively, those located WTRUs may be considered trusted and / or authenticated, such as via one or more separate means and / or (e.g., related) security information. The security information may be shared with the WTRU during registration and / or pre-configured within the WTRU. For example, when the WTRU receives a message from a located WTRU in the prioritized list of located WTRUs, the WTRU may use the information shared during registration and / or the information pre-configured (e.g., in the second method) to authenticate the located WTRU (e.g., in one method).

[0091] For example, when the network (e.g., 5GCN) initiates a location request via a located WTRU using a trigger condition that triggers a MO-LR request from a target (e.g., out-of-coverage) WTRU, the network (e.g., 5GCN) may include verification information and / or parameters (e.g., required parameters) for determining the MO-LR request (e.g., AF, LCS client type) at the target WTRU in the location request message. The target WTRU may (e.g., internally) check the information to verify that the location request is legitimate and / or authorized. And the target WTRU may use the received information (e.g., recipient of the location information, quality of service (QoS)) to determine the MO-LR request (e.g., with necessary parameters).

[0092] For example, when the network (e.g., 5GCN) requests a located WTRU to perform sidelink positioning with a target WTRU, the network (e.g., 5GCN) may include an indication of the application of the sidelink positioning in the request, and / or the indication of the application of the sidelink positioning may be forwarded to the target WTRU. For example, when the target WTRU determines to follow the request received from the located WTRU, the target WTRU may utilize the indication of the application of the sidelink positioning. For example, when the indication of the application of the sidelink positioning indicates emergency services, the target WTRU may determine not to ignore the request, and / or may respond to the request from the located WTRU and / or perform sidelink positioning. The indication of the application of the sidelink positioning may be included in a secure container, for example, to indicate origin and / or integrity.

[0093] Figure 4An example process 400 of a mobile terminated location request (MT-LR) to a target (e.g., out of coverage) WTRU 407 via a located WTRU 405 is depicted. The example addresses how to provide location information of an out of coverage WTRU (e.g., target WTRU 407) and how to provide security protection for the message to avoid attacks, such as from malicious WTRUs. Figure 4 , at 402, if, for example, the WTRU is capable of SL positioning, the WTRU may notify this capability during registration. Additionally or alternatively, when the WTRU is out of coverage, the WTRU may notify that the WTRU is capable of SL positioning, and / or when the WTRU is out of coverage, the WTRU may be provided with parameters for SL positioning. These parameters include one or more of the following: target WTRU ID information (e.g., for discovery), PC5 link establishment (e.g., for SL positioning applications), ProSe service information (e.g., for SL positioning applications), security credentials, or parameters for deriving security credentials. The parameters for deriving security credentials can be used to verify and / or decrypt a secure container for a location service request from a network (e.g., 5GCN). For example, during the registration phase, the WTRU may be provided with a list of located WTRU ID information. The target WTRU 407 may be provided with or pre-configured with a list of located WTRUs in priority order.

[0094] At 404, an access control and mobility management function (AMF) 401 may be triggered to initiate a location request for a WTRU (e.g., a target WTRU 407). The AMF 401 may determine a list of located WTRUs for reaching the target WTRU 407 in a PC5 communication based on the last known location and / or other information (e.g., analysis information of the expected location of the target WTRU 407). Additionally or alternatively, the AMF 401 may determine the list of located WTRUs, for example, when the AMF 401 determines that the target WTRU 407 is unreachable. The AMF 401 may, for example, include a security container in the location request to protect information to be forwarded to the target WTRU 407.

[0095] The information in the secure container may be protected by encryption and / or integrity protection. Additionally or alternatively, the secure container may be protected by security credentials that may be shared between the network (e.g., 5GCN) and the target WTRU 407 and / or derived from information shared between the network (e.g., 5GCN) and the target WTRU 407, for example.

[0096] The information in the secure container may include information for verifying the location request. The information (e.g., for verifying the location request) may include one or more of the following: AF ID and / or LCS client information, requested location information of the target WTRU 407, service and / or application type for SL positioning, requested positioning method, candidate located WTRU list, QoS information of the location request, type of location request (e.g., immediate location request, delayed location request with trigger condition), or signature and / or information for integrity check and related security parameters to be used for decryption and / or verification of the secure container. For example, based on the security mechanism (e.g., when different security mechanisms are used), the signature or information for integrity check and the security parameters may be different. Additionally or alternatively, the AMF 401 may determine a prioritized list of located WTRUs and / or notify the location management function (LMF) 403. Alternatively or additionally, the LMF 403 may maintain a prioritized list of located WTRUs and / or a prioritized list of located WTRUs. For example, when the LMF 403 receives a location request for a target WTRU 407 (eg, which is out of coverage), the LMF 403 may select a list of located WTRUs for obtaining the location of the target WTRU 407 .

[0097] At 406, the LMF 403 may transmit a location request to the located WTRU 405. For example, when the LMF 403 receives the location request from the AMF 401, the LMF 403 may transmit a network (NW) triggered location request to the located WTRU 405. The network (NW) triggered SL location request may be transmitted via the RAN, for example, to a located WTRU in a list of located WTRUs. The list of located WTRUs may be received from the AMF 401 and / or maintained by the LMF 403. The LMF 403 may include the security container information in the SL location request transmitted, for example, to the located WTRU.

[0098] At 408, the located WTRU 405, which has received a NW-triggered SL positioning request from the LMF 403 via the RAN, may trigger a PC5 discovery procedure to discover the target WTRU 407. The located WTRU 405 may include the target WTRU's ID information and / or security container in the solicitation message, for example, when the located WTRU 405 transmits the request message. The target WTRU's ID information may be provided at the target WTRU 407 during the registration phase and / or may be provided to the located WTRU 405 in the SL positioning request, for example, by the LMF 403. At 408, if the positioned WTRU 405 receives a NW-triggered SL positioning request and the target WTRU 407 has already established a PC5 unicast link (which may be determined using the target WTRU ID information), the positioned WTRU 405 may skip the discovery phase at 408 and / or at 410 and / or perform SL positioning at 412, where the positioned WTRU 405 may include a security container in the SL positioning request to the target WTRU 407. At 412, the positioned WTRU 405 may include a security container in the SL positioning request to the target WTRU 407, for example, to perform SL positioning.

[0099] At 410, the target WTRU 407 may decode the solicitation message and the information in the secure container, for example, when the target WTRU 407 receives a solicitation message indicating the target WTRU 407. After verifying the message using the information in the secure container, the target WTRU 407 may respond with a response message. The response message may include a located WTRU ID (e.g., which is the sender of the solicitation message). When the solicitation message is not verified by the target WTRU 407, the target WTRU 407 may reject the solicitation message and / or ignore the solicitation message. Alternatively or additionally, when the target WTRU 407 receives a solicitation message from a WTRU in a prioritized list of located WTRUs (e.g., the located WTRU 405), the target WTRU 407 may individually authenticate the authentication message.

[0100] At 408 or at 410, the target WTRU 407 may receive multiple discovery messages and / or SL positioning requests from multiple located WTRUs. The security containers included in those messages may indicate the same information in the security container. For example, for each target WTRU selection, the target WTRU 407 may respond to only one located WTRU, which may avoid duplication and / or replay attacks.

[0101] At 412, the located WTRU 405 may perform SL positioning with the target WTRU 407, for example, using a PC5 signaling message. After receiving a response message from the target WTRU 407 including, for example, located WTRU information, the located WTRU 405 may perform SL positioning with the target WTRU 407. Alternatively or additionally, the target WTRU 407 and the located WTRU 405 may establish a PC5 unicast connection. The located WTRU 405 may perform SL positioning with the target WTRU 407 over the PC5 connection. After receiving, for example, a SL positioning request with a secure container from the located WTRU 405, the target WTRU 407 may verify the secure container and / or accept the SL positioning request after successful verification.

[0102] At 414, the positioned WTRU 405 may respond to the LMF 403, e.g., after successfully completing the SL positioning procedure. The positioned WTRU 405 may respond to the LMF 403 via the RAN, e.g., using a NW-triggered SL positioning response. The NW-triggered SL response may include the results of the SL positioning with the target WTRU 407. The positioned WTRU 405 may additionally or alternatively include positioning information of the positioned WTRU 405 in the NW-triggered SL positioning response.

[0103] At 416, the LMF 403 may determine the location information of the target WTRU 407, for example, by using the SL location information of the target WTRU 407 and / or the location information of the located WTRU 405. The LMF 403 may determine the location information of the target WTRU 407 after receiving the NW-triggered SL location response from the located WTRU 405. The LMF 403 may respond to the AMF 401 with the location information of the target WTRU 407, which may be determined by the LMF 403, for example.

[0104] Figure 5 5 is an example process 500 for a mobile terminated location request (MT-LR) using sidelink (SL) positioning signaling with a secure container. Figure 5As depicted, the procedure for performing MT-LR may utilize SL positioning signaling with a secure container. The positioned WTRU 505 may exchange information in a secure container. The secure container may be received from the LMF 503. The positioned WTRU 505 may receive a verification response, for example, during a SL positioning signaling procedure following a discovery procedure. At 502, for example, if the WTRU is capable of SL positioning, the WTRU may advertise its capabilities during registration. Additionally or alternatively, when the WTRU is out of coverage, the WTRU may advertise its SL positioning capabilities and / or (for example, when out of coverage) the WTRU may be provided with parameters for SL positioning. These parameters may include one or more of the following: target WTRU ID information (e.g., for discovery and / or PC5 link establishment for SL positioning applications), ProSe service information (e.g., for SL positioning applications), security credentials, and / or parameters for deriving security credentials. The security credentials and / or parameters used to derive the security credentials may be used to authenticate and / or decrypt the secure container, for example, for location service requests from the 5GCN. The target WTRU 507 may be provided with a list of located WTRU ID information.

[0105] At 504, the AMF 501 may be triggered to initiate a location request for a WTRU, such as a target WTRU 507. In the location request, the AMF 501 may include a security container to protect the information to be forwarded to the target WTRU 507. At 506, the LMF 503 may transmit a NW-triggered SL location request to the selected located WTRU, such as via the RAN. The SL location request may include the security container information.

[0106] At 508 and 510, the located WTRU 505 may perform a PC5-based discovery procedure to discover the target WTRU 507, and perform a PC5 unicast connection establishment procedure with the target WTRU 507 after the discovery procedure with the target WTRU 507 is successful. The located WTRU 505 may transmit a solicitation message to the target WTRU 507. The solicitation message may include target WTRU information. The located WTRU 505 may receive a response message from the target WTRU 507. The located WTRU 505 may trigger a PC5 unicast connection establishment procedure with the target WTRU 507. The located WTRU 505 may, for example, transmit an announce message to the target WTRU 507. The announce message may include located WTRU information and / or target WTRU information. The target WTRU 507 may trigger a PC5 unicast connection establishment procedure with the located WTRU 505. The notification message (e.g., solicitation message) from the located WTRU 505 may include security information (e.g., a cryptographic hash of the target WTRU ID or a protected indicator showing that the request is from the network). Using this security information, the target WTRU 507 may check to determine whether the discovery request from the located WTRU 505 complies with the network's request and / or authorization.

[0107] At 512, the located WTRU 505 may transmit a SL positioning request, e.g., after successfully establishing a PC5 unicast connection with the target WTRU 507. The SL positioning request may include security container information. The security container information may be received, e.g., from the LMF 503 via the RAN. Alternatively or additionally, the target WTRU 507 may authenticate the located WTRU 505 in a separate manner, e.g., when the target WTRU 507 finds the located WTRU 505 in the prioritized list of located WTRUs and establishes a PC5 unicast connection with the located WTRU.

[0108] At 514, the target WTRU 507 may accept the request using a SL positioning response, e.g., after validating the message using information in the secure container. At 516, the located WTRU 505 may perform SL positioning with the target WTRU 507, e.g., after receiving the SL positioning response. At 518, the located WTRU 505 may respond to the LMF 503 using a NW-triggered SL positioning response, e.g., via the RAN. The SL positioning response may include the result of the SL positioning with the target WTRU 507. After successfully completing the SL positioning procedure, the located WTRU 505 may respond to the LMF 503. At 520, the LMF 503 may determine the location information of the target WTRU 507, e.g., by using the SL positioning information of the target WTRU 507 and / or the location information of the located WTRU 505. The LMF 503 may determine the location information of the target WTRU 507, e.g., after receiving a NW-triggered SL positioning response from the located WTRU 505. The LMF 503 may respond to the AMF 501 with the location information of the target WTRU 507.

[0109] Fig. 6A and Figure 6B An example process 600 for a mobile originated location request (MO-LR) for a target out of coverage WTRU is depicted. Fig. 6A and Figure 6B The location information of an out-of-coverage WTRU provided using a 5G MO-LR type location request is illustrated. The MO-LR type location request may be requested by a target WTRU, for example, when one or more conditions that trigger the request are met. The information required to form the MO-LR type location request may be provided before the MO-LR type location request, for example, by the 5GCN. For example, the location request from the AMF may be a delayed location request. For example, when the trigger condition is met, the target WTRU may initiate a 5G MO-LR. For example, when the target WTRU is out of coverage (for example, in order to transmit a 5G MO-LR type location request), there may be a method that enables the target WTRU to select a located WTRU authorized by the 5GCN as the located WTRU.

[0110] refer to Fig. 6A, at 602, if the WTRU is capable of SL positioning, the WTRU may advertise this capability during registration. Additionally or alternatively, when the WTRU is out of coverage, the WTRU may advertise that it is capable of SL positioning, and / or when the WTRU is out of coverage, the WTRU may be provided with parameters for SL positioning. These parameters may include one or more of the following: target WTRU ID information (e.g., for discovery and / or PC5 link establishment for SL positioning applications), ProSe service information (e.g., for SL positioning applications), security credentials and / or parameters for deriving security credentials. The security credentials and / or parameters for deriving security credentials can be used to verify and / or decrypt a secure container, for example, for a location service request from the 5GCN. For example, the target WTRU 607 may receive a list of located WTRU ID information from the 5GC. The list may include one or more located WTRUs 605, 609. Additionally or alternatively, the target WTRU 607 may be transmitted or may be pre-configured with a prioritized list of located WTRUs (e.g., from the 5GC).

[0111] At 604, the AMF 601 may be triggered to initiate a location request for a WTRU (e.g., a target WTRU 607). In the location request, the AMF 601 may include a security container, for example, to protect information to be forwarded to the target WTRU 607. At 606, the LMF 603 may transmit a NW-triggered SL location request to the selected located WTRU, for example, via the RAN. After receiving the location request, the LMF 603 may transmit the NW-triggered SL location request. The NW-triggered SL location request may include security container information.

[0112] At 610 and 612, the located WTRU_1 605 that receives the NW-triggered SL positioning request may perform a PC5-based discovery procedure and / or a PC5 unicast connection establishment procedure with the target WTRU 607, for example, after the discovery procedure with the target WTRU 607 is successful. The PC5-based discovery procedure may be used to discover the target WTRU 607. For example, the located WTRU_1 605 may transmit a solicitation message, for example, including target WTRU information, and / or may receive a response message from the target WTRU 607. The located WTRU 605, 609 may initiate a PC5 unicast connection establishment procedure with the target WTRU 607. For another example, the located WTRU 605, 609 may transmit a notification message. The notification message may include the located WTRU information and / or the target WTRU information. For example, after receiving the announcement message, the target WTRU 607 may initiate a PC5 unicast connection establishment procedure with the located WTRUs 605 , 609 .

[0113] At 614, the located WTRU_1 605 may transmit a SL positioning request, for example, after successfully establishing a PC5 unicast connection with the target WTRU 607. The SL positioning request may include, for example, secure container information that may be received from the LMF 603 via the RAN. Alternatively or additionally, the target WTRU 607 may authenticate the located WTRU 605, 609 in a separate manner, for example, when the target WTRU 607 discovers the located WTRU 605, 609 in the prioritized list of located WTRUs and / or establishes a PC5 unicast connection with the located WTRU.

[0114] At 616, the target WTRU 607 may respond with a SL positioning response, for example, after verifying the message using information in a secure container. The secure container may include a list of located WTRUs. The list of located WTRUs may indicate legitimate and / or authorized located WTRUs. The target WTRU 607 may store one or more trigger conditions. For example, when the SL positioning request indicates that the requested location request type is a delayed location request, the target WTRU 607 may store one or more of these trigger conditions. The target WTRU 607 may initiate a 5GC-MO-LR type location request. For example, when one or more of these trigger conditions are met, the target WTRU 607 may initiate a 5GC-MO-LR type location request.

[0115] At 618, the located WTRU_1 605 may respond to the LMF 603 with a NW triggered SL Positioning Response, e.g., to indicate that the request was successfully delivered. After receiving the SL Positioning Response, the located WTRU_1 605 may respond to the LMF 603 with a NW triggered SL Positioning Response. At 620, the LMF 603 may respond to the AMF 601 with a Positioning Response, e.g., to indicate that the location request was successfully delivered. For example, after receiving the SL Positioning Response, the LMF 603 may respond to the AMF 601 with a Location Response.

[0116] refer to Figure 6B, the example process 600 of a mobile originated location request (MO-LR) for a target out of coverage WTRU continues. At 622, the target WTRU 607 may initiate a procedure for a 5GC-MO-LR request, e.g., when one or more trigger conditions are met. At steps 624 and 626, the target WTRU 607 may perform a discovery procedure, e.g., to find available located WTRUs 605, 609. When the target WTRU 607 discovers a located WTRU 609 (e.g., WTRU_2 in FIG. 6 ), the target WTRU 607 may check whether the located WTRU_2 609 is in a list of located WTRUs, e.g., received at 612.

[0117] At 628, the target WTRU 607 may initiate a PC5 unicast connection establishment, for example, after successfully verifying the located WTRU_2 609 in the located WTRU list. At 630, the target WTRU 607 may transmit a NW-assisted SL positioning request to the located WTRU_2 609. The NW-assisted SL positioning request may include information for composing a 5GC-MO-LR request message at the located WTRU_2 609 (e.g., information about the consumer of the location information of the target WTRU 607, one or more of the AF ID and / or LCS client ID, QoS information of the location request, or the requested positioning method, etc.).

[0118] At 632, the target WTRU 607 and the positioned WTRU_2 609 may perform SL positioning. At 634, the positioned WTRU_2 609 may transmit a 5GC-MO-LR request to the LMF 603. The 5GC-MO-LR request message may include one or more of the target WTRU ID, the positioned WTRU ID, the consumer AF, the LCS client ID, or the result of the SL positioning between the positioned WTRU_2 609 and the target WTRU 607. The 5GC-MO-LR request message may include one or more of the QoS information of the location, the positioning information of the positioned WTRUs 605, 609, or the requested positioning method, etc.

[0119] At 636, the LMF 603 may perform procedures to determine the location information of the located WTRU_2 609, e.g., after receiving the 5GC-MO-LR request. At 638, the LMF 603 may transmit a location report to the AMF 601, e.g., after determining the location information of the target WTRU 607. The location report may include one or more of the location information of the target WTRU 607, the consumer AF and / or LCS client ID, or QoS information of the location information, etc.

[0120] 5G MO-LR may be requested by an application. For example, the location information of the WTRU may be obtained by the application and / or the request from the application may not be ignored. For example, in a disaster situation, it may be critical to identify the location of the WTRU in order to rescue people in danger. The location request may be responded to by the WRTU. For example, to indicate the severity of the location request, the location request information may include an indication of the application for side link positioning. For example, when the WRTU receives a location request with an indication of the application for side link positioning, the WRTU may determine that the location request cannot be ignored. For example, if the indication indicates emergency services, the location request may be responded to by the WRTU.

[0121] Figure 7 An example process 700 of an MT-LR to a target WTRU 707 using an existing connection with a located WTRU 705 is depicted. Figure 7 The location information of an out-of-coverage WTRU (eg, target WTRU 707) provided via the located WTRU 705 when the located WTRU 705 and the target WTRU 707 maintain a PC5 connection is illustrated.

[0122] At 702, for example, if the WTRU is capable of SL positioning, the WTRU may advertise its capability during registration. Additionally or alternatively, the WTRU may advertise its ability to perform SL positioning when the WTRU is out of coverage, and / or the WTRU may be provided with parameters, for example, for SL positioning when the WTRU is out of coverage. These parameters may include one or more of the following: target WTRU ID information (e.g., for discovery and / or PC5 link establishment for SL positioning applications), ProSe service information (e.g., for SL positioning applications), security credentials and / or parameters for deriving security credentials. The security credentials and / or parameters for deriving security credentials may be used to verify and / or decrypt, for example, a secure container for a location service request to a network (e.g., 5GCN). The target WTRU 707 may be provided with a list of located WTRU ID information.

[0123] At 704 and 706, the target WTRU 707 may initiate discovery with a WTRU in the located WTRU list (e.g., the located WTRU 705), for example, using the ID information. Additionally or alternatively, the target WTRU 707 may initiate a PC5 connection establishment with the located WTRU 705. For example, when the target WTRU 707 discovers the located WTRU 705 in the prioritized located WTRU list and establishes a PC5 unicast connection with the located WTRU, the target WTRU 707 may authenticate the located WTRU 705 in a separate manner. At 708, the target WTRU 707 may transmit a notification that the target WTRU 707 is connecting to the located WTRU 705. The notification may include the located WTRU information. Alternatively or additionally, the located WTRU 705 may transmit a notification to the target WTRU 707 that the located WTRU 705 is connected to the network (e.g., 5GCN). For example, for security reasons, the located WTRU 705 and / or the target WTRU 707 may include a signature of the target WTRU 705, e.g., in a notification indicating that the notification is from a genuine WTRU. The notification may be transmitted to the LMF 703, and / or the LMF 703 may maintain a list of located WTRUs and / or a status of the connection of the target WTRU 707 with the located WTRU.

[0124] At 710, the AMF 701 may be triggered to initiate a location request for the target WTRU 707. At 710, the AMF 701 may transmit the location request to the LMF 703, for example, when the AMF 701 knows that the target WTRU 707 is unreachable. The location request may include one or more of the target WTRU 707 information, a list of located WTRUs, and / or a secure container. The secure container may include protected location request information to the target WTRU 707. Additionally or alternatively, the AMF 701 may construct a prioritized list of located WTRUs (e.g., a prioritized ranked list of located WTRUs) and / or transmit the ranked WTRU list to the LMF 703. For example, when the located WTRU 705 is connected to the target WTRU 707, the AMF may include the located WTRU 705 in the ranked WTRU list. The AMF 701 may populate the list of located WTRUs using (e.g., using only) the located WTRUs 705 that inform the target WTRU 707 that it is connected. Additionally or alternatively, the AMF 701 may include one or more located WTRUs that are known to be in proximity to the located WTRU 705 and, for example, the located WTRU that informs the target WTRU 707 that it is connected. The information in the secure container may be protected by one or more of encryption protection, integrity protection, and / or security credentials. These security credentials may be shared between the network (e.g., 5GCN) and the target WTRU 707 and / or may be derived from information shared between the network (e.g., 5GCN) and the target WTRU 707. The information in the secure container may include information for verifying the location request (e.g., one or more of AF ID and / or LCS client information, requested location information of the target WTRU_1, service and / or application type for SL positioning, requested positioning method, a list of candidate located WTRUs, QoS information of the location request, or type of location request, etc.). The type of location request may include one or more of an immediate location request or a delayed location request with a trigger condition. The LMF 703 may maintain a list of located WTRUs. For example, when the LMF 703 receives a location request for a target WTRU 707 that is out of coverage, the LMF 703 may select the list of located WTRUs for obtaining the location of the target WTRU 707. For example, when the LMF 703 constructs the list of located WTRUs, the LMF 703 may include notifying the located WTRU 705 that the target WTRU 707 is connected.

[0125] At 712, the LMF 703 may transmit a NW-triggered SL positioning request (e.g., via the RAN) to a located WTRU in a list of located WTRUs, e.g., when the LMF 703 receives a location request indicating the target WTRU 707 from the AMF 701. The list of located WTRUs may be received from the AMF 701 and / or maintained by the LMF 703. The LMF 703 may include the secure container information in the SL positioning request transmitted to the located WTRU.

[0126] At 714, one or more located WTRUs (e.g., located WTRU 705) may discover a target WTRU 707, for example, when a located WTRU receives a NW-triggered SL location request. When the target WTRU 707 is discovered, the located WTRU 705 may establish a PC5 connection. For example, when a located WTRU 705 maintaining a PC5 connection with the target WTRU 707 receives a NW-triggered SL location request, the located WTRU 705 may forward the secure container and / or information associated with the secure container to the target WTRU 707 via the maintained PC5 connection. The target WTRU 707 may (e.g., subsequently) verify the secure container and the secure container contents. Alternatively or additionally, the target WTRU 707 may skip authentication of the located WTRU 705, or authenticate the located WTRU 705 in a separate manner, for example, when the target WTRU 707 is connected to a located WTRU 705 in a prioritized list of located WTRUs. At 716, the located WTRU 705 and the target WTRU 707 may perform SL positioning procedures over the maintained PC5 connection, e.g., after the target WTRU 707 successfully authenticates the secure container. Alternatively or additionally, the located WTRU 705 may independently perform SL positioning with the target WTRU 707. For example, even if no SL positioning request is received, the located WTRU 705 may transmit SL positioning information with target WTRU 707 information and / or other information (e.g., location information of the located WTRU 705 when the NW-triggered SL positioning request is received at 712). For example, if the located WTRU 705 is configured and / or there is an indication that the network (e.g., 5GCN) does not require authentication, the located WTRU 705 may skip 714.

[0127] At 718, the located WTRU 705 may respond to the LMF 703 via the RAN with a NW-triggered SL positioning response, e.g., after successfully completing the SL positioning procedure. The NW-triggered SL positioning response may include the result of the SL positioning with the target WTRU 707. The located WTRU 705 may include the positioning information of the located WTRU 705 in the NW-triggered SL positioning response. At 720, the LMF 703 may determine the location information of the target WTRU 707, e.g., after receiving the NW-triggered SL positioning response from the located WTRU 705. The LMF 703 may determine the location information of the target WTRU 707 by using the NW-triggered SL positioning response of the target WTRU 707.

[0128] 707 and / or the location information of the located WTRU 705 to determine the target WTRU

[0129] The LMF 703 may respond, for example, using the location information of the target WTRU 707.

[0130] AMF 701.

Claims

1. A method implemented by a first wireless transmit / receive unit (WTRU), the method comprising: receiving a first sidelink (SL) location request from a second WTRU, wherein the first SL location request includes configuration information and security information for verifying the first SL location request, the configuration information including one or more parameters for deriving security credentials for verifying the security information in the first SL location request; transmitting a first SL positioning response to the second WTRU, wherein the first SL positioning response is transmitted based on verification of the first SL positioning request using at least the security information; and Perform SL positioning with the second WTRU.

2. The method of claim 1 , wherein performing SL positioning with the second WTRU comprises: An indication of one or more range measurements or direction measurements associated with the second WTRU is received.

3. The method of claim 1 , wherein performing SL positioning with the second WTRU comprises: One or more range measurements or direction measurements associated with the second WTRU are determined.

4. The method of claim 1, wherein the security information is received in a first secure container, the first secure container being protected by the security credentials derived from the one or more parameters received in the configuration information.

5. The method according to claim 4, comprising: The validity of the first SL positioning request is verified by verifying the security information received in the first secure container.

6. The method according to claim 1, comprising: Discovery with the second WTRU is performed based on receiving a second SL positioning request from the network.

7. The method of claim 1, wherein the security information comprises one or more of: an application function (AF) ID, location service (LCS) client information, a location information request for the first WTRU, a service type, a second WTRU list, quality of service (QoS) information, or a type of location request.

8. The method of claim 1, wherein the first SL positioning request includes a second WTRU list in a second security container.

9. The method of claim 8, wherein verification of the first sidelink positioning request is based on one or more of: the security information, or the second WTRU being in the second WTRU list.

10. The method according to claim 1, comprising: A Mobile Originated Location Request (MO-LR) is initiated based on satisfying one or more triggering conditions.

11. A first wireless transmit / receive unit (WTRU), comprising: A processor, the processor being configured to: receiving a first sidelink (SL) location request from a second WTRU, wherein the first SL location request includes configuration information and security information for verifying the first SL location request, the configuration information including one or more parameters for deriving security credentials for verifying the security information in the first SL location request; transmitting a first SL positioning response to the second WTRU, wherein the first SL positioning response is transmitted based on verification of the first SL positioning request using at least the security information; and Perform SL positioning with the second WTRU.

12. The first WTRU of claim 11, wherein performing SL positioning with the second WTRU comprises: An indication of one or more range measurements or direction measurements associated with the second WTRU is received.

13. The first WTRU of claim 11 , wherein performing SL positioning with the second WTRU comprises: One or more range measurements or direction measurements associated with the second WTRU are determined.

14. The first WTRU of claim 11, wherein the security information is received in a first secure container, the first secure container being protected by the security credentials derived from the one or more parameters received in the configuration information.

15. According to claim 14, the first WTRU is configured to verify the validity of the first SL positioning request by verifying the security information received in the first security container.

16. The first WTRU of claim 11, wherein the first WTRU is configured to perform discovery with the second WTRU based on receiving a second SL positioning request from a network.

17. A first WTRU according to claim 11, wherein the security information includes one or more of the following: application function (AF) ID, location service (LCS) client information, location information request for the first WTRU, service type, second WTRU list, quality of service (QoS) information or type of location request.

18. The first WTRU of claim 11, wherein the first SL positioning request includes a second WTRU list in a second secure container.

19. The first WTRU of claim 18, wherein verification of the first sidelink positioning request is based on one or more of: the security information, or the second WTRU being in the second WTRU list.

20. The first WTRU of claim 11 configured to initiate a Mobile Originated Location Request (MO-LR) based on satisfying one or more trigger conditions.

Images