Sidelink positioning operation based on WTRU, which functions as a positioning server.

Abstract

A system and method for sidelink positioning operations are described herein based on the interaction between a Location Management Function (LMF) and a sidelink positioning service radio transceiver unit (WTRU). Sidelink (SL) positioning operations can be performed based on the interaction between a network entity and an SL positioning server WTRU. The WTRU can receive configuration information associated with SL positioning assistance. The WTRU can send positioning service messages to the network entity. The WTRU can determine an SL positioning service request associated with a target WTRU. The WTRU can determine positioning service information. Positioning services can be associated with a target WTRU. The WTRU can receive a message from the network entity, which may include a candidate list of SL reference WTRUs (e.g., a first candidate list of SL reference WTRUs). The determined SL reference WTRU may be from the candidate list of SL reference WTRUs.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application claims priority to U.S. Provisional Patent Application No. 63 / 465,701, filed May 11, 2023, the disclosure of which is hereby incorporated by reference in its entirety.

Background Art

[0002] Mobile communication using wireless communication has been continuously evolving. The fifth generation can be called 5G. Previous (legacy) generations of mobile communication can be, for example, the fourth generation (4G) Long - Term Evolution (LTE).

Summary of the Invention

[0003] A system and method for sidelink positioning operations are described herein based on the interaction between a location management function (LMF) and a wireless transmit - receive unit (WTRU) of a sidelink positioning service.

[0004] Sidelink (SL) positioning operations can be performed based on interactions between a network entity (e.g., a location management function) and an SL positioning server WTRU. A WTRU can include a Sidelink (SL) positioning server WTRU. A WTRU can be associated with one or more locations or service areas. A WTRU can receive configuration information associated with SL positioning assistance. A WTRU can send positioning service messages to a network entity. Capability information may indicate that a WTRU can function as an SL positioning server WTRU. A WTRU can determine an SL positioning service request associated with a target WTRU. An SL positioning service request may indicate one or more of the following: target WTRU ID, reference WTRU information, and positioning requirement information. An SL positioning service request may indicate a first WTRU and a second WTRU (e.g., a first target WTRU and a second target WTRU). A WTRU can determine positioning service information associated with a positioning service. A positioning service may be associated with a target WTRU. Positioning service information may include a positioning method and / or an SL reference WTRU. Positioning service information may be determined based on one or more of the configuration information and / or indications received from a network entity associated with SL positioning assistance. A WTRU may receive a message from a network entity, which may include a candidate list of SL reference WTRUs (e.g., a first candidate list of SL reference WTRUs). The determined SL reference WTRU may be from the candidate list of SL reference WTRUs. A WTRU may be colocated with a target WTRU or an SL reference WTRU. A WTRU may send an SL positioning response to a target WTRU. The SL positioning response may indicate the determined positioning service information. [Brief explanation of the drawing]

[0005] [Figure 1A] This is a system diagram showing an exemplary communication system in which one or more disclosed embodiments may be implemented. [Figure 1B] This is a system diagram showing an exemplary wireless transceiver unit (WTRU) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1C] This is a system diagram showing an exemplary radio access network (RAN) and an exemplary core network (CN) that may be used in the communication system shown in Figure 1A, according to one embodiment. [Figure 1D] This is a system diagram showing further exemplary RANs and CNs that may be used in the communication system shown in Figure 1A according to one embodiment. [Figure 2] This figure shows an exemplary reference model of a network for location services. [Figure 3] This figure illustrates an exemplary procedure for SL positioning operations involving one or more interactions between the LMF and the SL positioning server WTRU. [Modes for carrying out the invention]

[0006] Figure 1A shows an exemplary communication system 100 that can implement one or more disclosed embodiments. The communication system 100 may be a multiple access system that provides content such as voice, data, video, messaging, and broadcast to multiple radio users. The communication system 100 may enable multiple radio users to access such content through the sharing of system resources, including radio 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), quadrature 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, and filter-bank multi-carrier (FBMC).

[0007] As shown in Figure 1A, the communication system 100 may include wireless transceiver units (WTRUs) 102a, 102b, 102c, and 102d, RAN 104 / 113, CN 106 / 115, public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, but it will be understood that the disclosed embodiments assume any number of WTRUs, base stations, networks, and / or network elements. Each of the WTRUs 102a, 102b, 102c, and 102d may be any type of device configured to operate and / or communicate in a wireless environment. For example, WTRU102a, 102b, 102c, and 102d may all be referred to as “stations” and / or “STAs,” which may be configured to transmit and / or receive radio signals and may include user equipment (UEs), mobile stations, fixed or mobile subscriber units, subscription-based units, pagers, cellular telephones, personal digital assistants (PDAs), smartphones, laptops, notebooks, personal computers, radio sensors, hotspots or Mi-Fi devices, IoT devices, watches or other wearables, head-mounted displays (HMDs), vehicles, drones, medical equipment and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other radio devices operating in the context of industrial and / or automated processing chains), consumer electronic devices, and devices operating on commercial and / or industrial radio networks. WTRU102a, 102b, 102c, and 102d may all be referred to as UEs interchangeably.

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

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

[0010] Base stations 114a, 114b may communicate with one or more WTRUs 102a, 102b, 102c, 102d via an air interface 116 which may be any suitable radio 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).

[0011] More specifically, as described 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, and SC-FDMA. For example, base stations 114a and WTRUs 102a, 102b, and 102c in RAN 104 / 113 may implement radio technologies such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA) that can establish air interfaces 115 / 116 / 117 using broadband CDMA (WCDMA®). WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Advanced HSPA (HSPA+). HSPA may include High Speed ​​Downlink (DL) Packet Access (HSDPA) and / or High Speed ​​UL Packet Access (HSUPA).

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

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

[0014] In one embodiment, base station 114a and WTRU 102a, 102b, 102c can implement multiple radio access technologies. For example, base station 114a and WTRU 102a, 102b, 102c can implement LTE radio access and NR radio access together, for example, using the dual connectivity (DC) principle. Thus, the air interface utilized by WTRU 102a, 102b, 102c may be characterized by transmissions between multiple types of radio access technologies and / or multiple types of base stations (e.g., eNB and gNB).

[0015] In other embodiments, base stations 114a and WTRUs 102a, 102b, and 102c may implement wireless technologies such as IEEE 802.11 (i.e., WiFi (Wireless Fidelity)), IEEE 802.16 (i.e., WiMAX (Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Provisional Standard 2000 (IS-2000), Provisional Standard 95 (IS-95), Provisional Standard 856 (IS-856), GSM (Registered Trademark) (Global System for Mobile communications), GSM Advanced High-Speed ​​Data Rate (EDGE), and GSM EDGE (GERAN).

[0016] In Figure 1A, base station 114b may be, for example, a wireless router, home NodeB, home eNodeB, or access point, and may utilize any suitable RAT to facilitate wireless connectivity in local areas such as workplaces, homes, vehicles, premises, industrial facilities, aerial corridors (for use by drones), roads, etc. In one embodiment, base station 114b and WTRU 102c, 102d may implement wireless technology such as IEEE 802.11 to establish a wireless local area network (WLAN). In one embodiment, base station 114b and WTRU 102c, 102d may implement wireless technology such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, base station 114b and WTRU 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 femtocell. As shown in Figure 1A, base station 114b may have a direct connection to the internet 110. Therefore, base station 114b does not need to access the internet 110 via CN106 / 115.

[0017] RAN104 / 113 may communicate with CN106 / 115, which may be any type of network configured to provide voice, data, applications, and / or VoIP services to one or more of WTRU102a, 102b, 102c, and 102d. The data may have various quality of service (QoS) requirements, such as different throughput requirements, latency requirements, fault tolerance requirements, reliability requirements, data throughput requirements, and mobility requirements. CN106 / 115 may provide call control, billing services, mobile location services, prepaid calling, internet connectivity, video distribution, and / or perform high-level security functions such as user authentication. Although not shown in Figure 1A, it should be understood that RAN104 / 113 and / or CN106 / 115 may communicate directly or indirectly with other RANs employing the same RAT as RAN104 / 113 or different RATs. For example, in addition to connecting to RAN104 / 113, which may utilize NR radio technology, CN106 / 115 may also communicate with another RAN (not shown) employing GSM, UMTS, CDMA2000, WiMAX, E-UTRA, or WiFi radio technology.

[0018] CN106 / 115 can also function as a gateway for WTRU102a, 102b, 102c, 102d to access PSTN108, the Internet 110, and / or other networks 112. PSTN108 may include a circuit-switched telephone network providing basic telephone services (POTS). The Internet 110 may include a global system of interconnected computer networks and devices using common communication protocols such as TCP, UDP, and / or IP in the TCP / IP Internet Protocol Suite. Network 112 may include wired and / or wireless networks owned and / or operated by other service providers. For example, network 112 may include another CN connected to one or more RANs that may employ the same RAT as RAN104 / 113 or a different RAT.

[0019] Some or all of the WTRUs 102a, 102b, 102c, and 102d in the communication system 100 may include multimode capability (for example, WTRUs 102a, 102b, 102c, and 102d may include multiple transceivers for communicating with different radio networks via different radio links). For example, WTRU 102c shown in Figure 1A may be configured to communicate with a base station 114a that may employ cellular-based radio technology and with a base station 114b that may employ IEEE 802 radio technology.

[0020] Figure 1B is a system diagram showing an example of WTRU102. As shown in Figure 1B, WTRU102 may include, in particular, a processor 118, a transceiver 120, a transceiver element 122, a speaker / microphone 124, a keypad 126, a display / touchpad 128, non-removable memory 130, removable memory 132, a power supply 134, a GPS chipset 136, and / or other peripherals 138. It will be understood that WTRU102 may comprise any subcombination of the aforementioned elements while maintaining consistency with the embodiment.

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

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

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

[0024] The transceiver 120 may be configured to modulate signals to be transmitted by the transceiver element 122 and demodulate signals received by the transceiver element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers to enable the WTRU 102 to communicate via multiple RATs such as, for example, NR and IEEE 802.11.

[0025] The processor 118 of the WTRU102 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 from them. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad 128. Furthermore, the processor 118 may access information in any type of suitable memory, such as non-removable memory 130 and / or removable memory 132, and store data therein. Non-removable memory 130 may include RAM, ROM, a hard disk, or any other type of memory storage device. Removable memory 132 may include a SIM card, a memory stick, a secure digital (SD) memory card, and the like. In other embodiments, the processor 118 may access and store data in memory that is not physically located on the WTRU 102, such as on a server or home computer (not shown).

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

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

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

[0029] WTRU102 may include a full-duplex radio where the transmission and reception of some or all of the signal (e.g., related to a particular subframe for both UL (e.g., for transmission) and downlink (e.g., for reception)) may be in parallel and / or simultaneous. The full-duplex radio may include an interference management unit to reduce and / or substantially eliminate self-interference through signal processing via either hardware (e.g., chokes) or a processor (e.g., a separate processor (not shown) or processor 118). In one embodiment, WTRU102 may include a half-duplex radio for the transmission and reception of some or all of the signal (e.g., related to a particular subframe for either UL (e.g., for transmission) or downlink (e.g., for reception)).

[0030] Figure 1C is a system diagram showing RAN104 and CN106 according to one embodiment. As described above, RAN104 employs E-UTRA wireless technology and can communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN104 may also communicate with CN106.

[0031] RAN104 may include eNode-B160a, 160b, and 160c, but it will be understood that RAN104 may include any number of eNode-B while maintaining consistency with the embodiment. Each of eNode-B160a, 160b, and 160c may be equipped with one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, eNode-B160a, 160b, and 160c may implement MIMO technology. Thus, eNode-B160a may use multiple antennas, for example, to transmit a radio signal to and / or receive a radio signal from WTRU102a.

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

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

[0034] MME162 may be connected to each of the eNodeB160a, 160b, and 160c within RAN104 via the S1 interface and may act as a control node. For example, MME162 may be responsible for authenticating users of WTRU102a, 102b, and 102c, activating / deactivating bearers, and selecting a specific serving gateway during the initial attachment of WTRU102a, 102b, and 102c. MME162 may provide control plane functionality for switching between RAN104 and other RANs (not shown) employing other radio technologies such as GSM and / or WCDMA.

[0035] SGW164 may be connected to each of the e-nodes B160a, 160b, and 160c in RAN104 via the S1 interface. Generally, SGW164 can route and forward user data packets to and from WTRU102a, 102b, and 102c. SGW164 may perform other functions such as anchoring the user plane during handovers between e-nodes B, triggering paging when DL data is available to WTRU102a, 102b, and 102c, and managing and remembering the context of WTRU102a, 102b, and 102c.

[0036] SGW164 may be connected to PGW166, which can provide WTRU102a, 102b, and 102c with access to a packet-switched network such as the Internet 110 to facilitate communication between WTRU102a, 102b, and 102c and IP-enabled devices.

[0037] CN106 can facilitate communication with other networks. For example, CN106 may provide WTRU102a, 102b, and 102c with access to a circuit-switched network such as PSTN108 to facilitate communication between WTRU102a, 102b, and 102c and conventional fixed communication devices. For example, CN106 may include or communicate with an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN106 and PSTN108. Furthermore, CN106 can provide WTRU102a, 102b, and 102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers.

[0038] Although the WTRU is shown as a wireless terminal in Figures 1A to 1D, in some typical embodiments, such a terminal may use a wired communication interface with a communication network (for example, temporarily or permanently).

[0039] In a typical embodiment, the other network 112 may be a WLAN.

[0040] A WLAN in Infrastructure Basic Service Set (BSS) mode has an access point (AP) for the BSS and one or more stations (STAs) associated with the AP. The AP may have access to or interface to a distribution system (DS) or another type of wired / wireless network that carries traffic to and / or from the BSS. Traffic originating outside the BSS and destined for the STA may arrive through the AP and be sent to the STA. Traffic originating from the STA to destinations outside the BSS may be sent to the AP and delivered to their respective destinations. Traffic between STAs within the BSS can be transmitted through the AP, for example, a source STA may send traffic to the AP, and the AP may deliver the traffic to the destination STA. Traffic between STAs within the BSS may be considered or referred to as peer-to-peer traffic. Peer-to-peer traffic can be transmitted (e.g., directly) between a source STA and a destination STA using a Direct Link Setup (DLS). In certain typical embodiments, the DLS may be an 802.11e DLS or an 802.11z Tunnel DLS (TDLS). WLANs using Independent BSS (IBSS) mode may not have access points (APs), and STAs within or using IBSS (e.g., all STAs) may communicate directly with each other. The IBSS communication mode is sometimes referred to as the “ad-hoc” communication mode in this specification.

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

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

[0043] Very high-throughput (VHT) STAs can support channels with widths of 20 MHz, 40 MHz, 80 MHz, and / or 160 MHz. 40 MHz and / or 80 MHz channels can be formed by combining consecutive 20 MHz channels. 160 MHz channels may be formed by combining eight consecutive 20 MHz channels or by combining two discontinuous 80 MHz channels, the latter sometimes referred to as an 80+80 configuration. In the 80+80 configuration, the channel-coded data passes through a segment parser, which splits the data into two streams. Inverse fast Fourier transform (IFFT) processing and time-domain processing can be performed independently on each stream. The streams are mapped to two 80 MHz channels, and the data is transmitted by the transmitting STA. At the receiver of the receiving STA, the above operation for the 80+80 configuration can be reversed, and the combined data can be transmitted to the media access control (MAC).

[0044] Sub-1GHz operating modes are supported by 802.11af and 802.11ah. Channel operating bandwidth and carrier are reduced in 802.11af and 802.11ah compared to those used in 802.11n and 802.11ac. 802.11af supports 5MHz, 10MHz, and 20MHz bandwidths in the TV white space (TVWS) spectrum, while 802.11ah supports 1MHz, 2MHz, 4MHz, 8MHz, and 16MHz bandwidths using the non-TVWS spectrum. According to a typical embodiment, 802.11ah can support meter-type control / machine-type communications, such as MTC devices in a macro coverage area. MTC devices may have limited functionality, including support for specific and / or limited bandwidths (e.g., support only). MTC devices may include batteries with battery life exceeding a threshold (e.g., maintaining a very long battery life).

[0045] A WLAN system can support multiple channels and channel bandwidths, including 802.11n, 802.11ac, 802.11af, and 802.11ah, and this WLAN system includes a channel that can be designated as the primary channel. The bandwidth of the primary channel may be 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 an STA from among all STAs operating in a BSS that support the minimum bandwidth operating mode. In the 802.11ah example, even if the AP and other STAs in the BSS support operating modes of 2MHz, 4MHz, 8MHz, 16MHz, and / or other channel bandwidths, the primary channel of an STA (e.g., an MTC-type device) that supports (e.g., only supports) the 1MHz mode may be 1MHz wide. Carrier sensing and / or network allocation vector (NAV) settings may depend on the status of the primary channel. For example, if the primary channel is busy because an STA (which only supports 1MHz operating mode) is transmitting to the AP, a large portion of the frequency band remains idle, and even if it were available, the entire available frequency band can be considered busy.

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

[0047] Figure 1D is a system diagram showing RAN113 and CN115 according to one embodiment. As described above, RAN113 can employ NR radio technology to communicate with WTRU102a, 102b, and 102c via the air interface 116. RAN113 may also communicate with CN115.

[0048] RAN113 may include gNB180a, 180b, and 180c, but it will be understood that RAN113 may include any number of gNBs while maintaining consistency with one embodiment. Each of gNB180a, 180b, and 180c may include one or more transceivers for communicating with WTRU102a, 102b, and 102c via the air interface 116. In one embodiment, gNB180a, 180b, and 180c can implement MIMO technology. For example, gNB180a and 108b can transmit and / or receive signals to and from gNB180a, 180b, and 180c using beamforming. Thus, for example, gNB180a can transmit and / or receive radio signals to and from WTRU102a using multiple antennas. In one embodiment, gNB180a, 180b, and 180c can implement carrier aggregation technology. For example, gNB180a can transmit multiple component carriers to WTRU102a (not shown). A subset of these component carriers may be on the unlicensed spectrum, and the remaining component carriers may be on the licensed spectrum. In one embodiment, gNB180a, 180b, and 180c can implement Coordinated Multi-Point (CoMP) technology. For example, WTRU102a can receive coordinated transmissions from gNB180a and gNB180b (and / or gNB180c).

[0049] WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using transmissions associated with scalable numerology. For example, OFDM symbol spacing and / or OFDM subcarrier spacing may vary by different transmissions, different cells, and / or different parts of the radio transmission spectrum. WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using subframes or transmit time intervals (TTIs) of varying or scalable lengths (e.g., varying numbers of OFDM symbols and / or varying lengths of absolute time duration).

[0050] gNB180a, 180b, and 180c can be configured to communicate with WTRU102a, 102b, and 102c in standalone and / or non-standalone configurations. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c without accessing other RANs (e.g., e-nodes B160a, 160b, and 160c). In a standalone configuration, WTRU102a, 102b, and 102c can utilize one or more gNB180a, 180b, and 180c as mobility anchor points. In a standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c using signals in unlicensed bands. In a non-standalone configuration, WTRU102a, 102b, and 102c can communicate with gNB180a, 180b, and 180c while also communicating with other RANs such as eNode-B160a, 160b, and 160c. For example, WTRU102a, 102b, and 102c can implement the DC principle to communicate with one or more gNB180a, 180b, and 180c and one or more eNodes B160a, 160b, and 160c almost simultaneously. In a non-standalone configuration, eNodes B160a, 160b, and 160c can act as mobility anchors for WTRU102a, 102b, and 102c, and gNB180a, 180b, and 180c can provide additional coverage and / or throughput to service WTRU102a, 102b, and 102c.

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

[0052] The CN115 shown in Figure 1D may include at least one AMF182a, 182b, at least one UPF184a, 184b, at least one Session Management Function (SMF)183a, 183b, and optionally a Data Network (DN)185a, 185b. Although each of the above elements is shown as part of CN115, it should be understood that any of these elements may be owned and / or operated by an entity other than the CN operator.

[0053] AMF 182a, 182b may be connected to one or more gNB180a, 180b, 180c in RAN113 via the N2 interface and function as a control node. For example, AMF182a, 182b may be responsible for user authentication of WTRU102a, 102b, 102c, support for network slicing (e.g., handling different PDU sessions with different requirements), selection of specific SMF183a, 183b, management of registration areas, termination of NAS signaling, mobility management, etc. Network slicing may be used by AMF182a, 182b to customize CN support for WTRU102a, 102b, 102c based on the type of service being utilized by WTRU102a, 102b, 102c. For example, various network slices can be established for various use cases, such as services that rely on ultra-high reliability low latency (URLLC) access, services that rely on extended large-scale mobile broadband (eMBB) access, and services for machine-type communications (MTC) access. The AMF162 may provide control plane functionality for switching between RAN113 and other RANs (not shown) that use other radio technologies such as LTE, LTE-A, LTE-A Pro, and / or non-3GPP access technologies such as WiFi.

[0054] SMF183a and 183b may be connected to AMF182a and 182b in CN115 via the N11 interface. SMF183a and 183b may also be connected to UPF184a and 184b in CN115 via the N4 interface. SMF183a and 183b can select and control UPF184a and 184b and configure the routing of traffic through UPF184a and 184b. SMF183a and 183b can perform other functions such as managing and assigning UE IP addresses, managing PDU sessions, controlling policy enforcement and QoS, and providing downlink data notifications. PDU session types may be IP-based, non-IP-based, Ethernet®-based, etc.

[0055] UPF184a, 184b can be connected to one or more gNB180a, 180b, 180c in RAN113 via the N3 interface, which provides WTRU102a, 102b, 102c with access to packet-switched networks such as the Internet 110 and facilitates communication between WTRU102a, 102b, 102c and IP-enabled devices. UPF184, 184b can perform other functions such as packet routing and forwarding, enforcement of user plane policies, support for multi-homed PDU sessions, processing of user plane QoS, buffering of downlink packets, and providing mobility anchors.

[0056] CN115 can facilitate communication with other networks. For example, CN115 may include, or communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between CN115 and PSTN108. Furthermore, CN115 may provide WTRU102a,102b,102c with access to other networks 112, which may include other wired and / or wireless networks owned and / or operated by other service providers. In one embodiment, WTRU102a,102b,102c may be connected to local DN185a,185b through UPF184a,184b via an N3 interface to UPF184a,184b and an N6 interface between UPF184a,184b and data networks (DN)185a,185b.

[0057] With regard to Figures 1A to 1D and the corresponding descriptions therein, one or more, or all, of the functions described herein with respect to one or more of the WTRU102a to d, base stations 114a to b, e-nodes B160a to c, MME162, SGW164, PGW166, gNB180a to c, AMF182a to b, UPF184a to b, SMF183a to b, DN185a to b, and / or other devices described herein can be performed by one or more emulation devices (not shown). The emulation devices may be one or more devices configured to emulate one or more, or all, of the functions described herein. For example, emulation devices may be used to test other devices and / or to simulate network and / or WTRU functions.

[0058] Emulation devices can be designed to implement one or more tests of other devices in a lab environment and / or operator network environment. For example, one or more emulation devices can be fully or partially implemented and / or deployed as part of a wired and / or wireless network to perform one, more or all of its functions in order to test other devices in a communications network. One or more emulation devices can be temporarily implemented / deployed as part of a wired and / or wireless network to perform one, more or all of its functions. Emulation devices can be directly coupled to another device for testing purposes and / or can perform tests using wireless communication.

[0059] One or more emulation devices may perform one or more functions (including all functions) without being implemented / deployed as part of a wired and / or wireless communication network. For example, an emulation device may be used in a test scenario in a test lab and / or in a test scenario in a non-deployed (e.g., test) wired and / or wireless communication network to implement testing of one or more components. One or more emulation devices may be test equipment. Direct RF coupling and / or wireless communication via RF circuitry (e.g., which may have one or more antennas) may be used by the emulation device to transmit and / or receive data.

[0060] A system and method for sidelink positioning operations are described herein based on the interaction between a Location Management Function (LMF) and a Wireless Transceiver Unit (WTRU) for sidelink positioning services.

[0061] Sidelink (SL) positioning operations may be performed based on interactions between a network entity (e.g., a location management function) and an SL positioning server WTRU. A WTRU may include a Sidelink (SL) positioning server WTRU. A WTRU may be associated with one or more locations or service areas. A WTRU may receive configuration information associated with SL positioning assistance. A WTRU may send positioning service messages to the network entity. Capability information may indicate that a WTRU can function as an SL positioning server WTRU. A WTRU may determine an SL positioning service request associated with a target WTRU. An SL positioning service request may indicate one or more of the following: a WTRU ID, reference WTRU information, or positioning requirement information. An SL positioning service request may indicate a first WTRU and a second WTRU (e.g., a first target WTRU and a second target WTRU). A WTRU may determine positioning service information associated with the positioning service. A positioning service may be associated with a target WTRU. Positioning service information may include a positioning method and / or an SL reference WTRU. Positioning service information may be determined based on one or more configuration information associated with SL positioning assistance and / or indications received from a network entity. A WTRU may receive a message from a network entity, which may include a candidate list of SL reference WTRUs (e.g., a first candidate list of SL reference WTRUs). The determined SL reference WTRU may be from the candidate list of SL reference WTRUs. A WTRU may be colocated with a target WTRU or an SL reference WTRU. A WTRU may send an SL positioning response to a target WTRU. The SL positioning response may indicate the determined positioning service information.

[0062] A WTRU (e.g., a Sidelink (SL) positioning server WTRU) performs the following operations: receiving configuration information from network functions (NFs) such as policy control functions (PCFs) (e.g., for the SL positioning server WTRU to support SL positioning services); sending positioning service messages (e.g., to the LMF) that may indicate its ability to function as a positioning server WTRU (e.g., may include one or all actions supported as a positioning server WTRU); receiving a list of available positioned SL reference WTRUs (e.g., from the LMF) based on the server WTRU's location or service area; receiving a general resource pool (e.g., from the LMF) per area or per server WTRU if multiple server WTRUs are located in the same area (e.g., if the area definition may be determined by the LMF); and receiving messages via the PC5 link (e.g., from the target WTRU and / or reference WTRU), e.g., target WTRU ID, SL reference WTRU ID The system can: receive an SL positioning service request message which may include the ID, WTRU capabilities, NAS connectivity / non-NAS connectivity for each WTRU, and / or positioning requirements; determine a positioning method and / or an SL reference WTRU (e.g., based on the received input); interact with the LMF (e.g., exchange messages) to determine a positioning method and / or an SL reference WTRU for a given positioning service request; receive dedicated radio resources from the LMF for the requested positioning service (e.g., these resources may be used for PC5 communication between the target WTRU and the SL reference WTRU, and between the SL reference WTRU and the SL positioning WTRU); send a message via the PC5 link (e.g., to the target WTRU and / or SL reference WTRU) containing the selected positioning method, the selected SL reference WTRU, the respective target WTRUs (e.g., if the message may be sent to the reference WTRU), and the allocated radio resources; and / or perform one or more of the following operations (e.g., may be configured to do so).

[0063] Sidelink (SL) positioning operations may be performed and / or provided. SL positioning operations may include one or more interactions between the Location Management Function (LMF) and the Server WTRU.

[0064] The SL positioning server WTRU performs the following operations: receiving configuration information from network functions (NFs) such as policy control functions (PCFs) (for example, for the SL positioning server WTRU to support SL positioning services); sending positioning service messages to the LMF (which may include actions supported as a positioning server WTRU) that indicate its ability to function as a positioning server WTRU; receiving from the LMF, for example, a list of available positioned SL reference WTRUs based on the server WTRU's location or service area; receiving a general resource pool from the LMF per area or per server WTRU, for example, if multiple server WTRUs are located in the same area (for example, if the area definition may be determined by the LMF); and receiving messages via the PC5 link (for example, from the target WTRU and / or reference WTRU), for example, the target WTRU ID, SL reference WTRU ID, etc. The system can: receive an SL positioning service request message which may include the ID, WTRU capabilities, NAS connectivity / non-NAS connectivity for each WTRU, and / or positioning requirements; determine a positioning method and / or an SL reference WTRU (e.g., based on the received input); interact with the LMF (e.g., exchange messages) to determine a positioning method and / or an SL reference WTRU for a given positioning service request; receive dedicated radio resources from the LMF for the requested positioning service (e.g., these resources may be used for PC5 communication between the target WTRU and the SL reference WTRU, and between the SL reference WTRU and the SL positioning WTRU); send a message via the PC5 link (e.g., to the target WTRU and / or SL reference WTRU) containing the selected positioning method, the selected SL reference WTRU, the respective target WTRUs (e.g., if the message may be sent to the reference WTRU), and the allocated radio resources; and / or perform one or more of the following operations (e.g., may be configured to do so).

[0065] The target WTRU may send a sidelink positioning request message to the SL positioning server WTRU, which may include one or more located SL reference WTRU IDs, their status and capabilities, and / or positioning service requirements; receive a message from the server WTRU, which may include a selected positioning method; select an SL reference WTRU and / or allocate radio resources; and / or perform one or more of the following actions (for example, it may be configured to do so).

[0066] The SL reference WTRU may perform the following actions: send a sidelink positioning request message to the SL positioning server WTRU (which may include one or more positioned target WTRU IDs, their status and capabilities, and / or positioning service requirements (e.g., shared by the SL reference WTRU and target WTRUs, if available); receive a message from the server WTRU (e.g., if selected as the SL reference WTRU) which may include a selected positioning method, each target WTRU, and / or allocated radio resources; and / or perform one or more of these actions (e.g., may be configured to do so).

[0067] LMF may perform (for example, be configured to perform) one or more of the following actions: requesting PCF to send arbitrary policy updates based on the SL positioning server WTRU ID; sending a general resource pool (for example to the positioning server WTRU) per area or per WTRU when multiple WTRUs are located in a given area; sending dedicated resources for positioning service requests to the positioning server WTRU for PC5 communication between the target WTRU, the SL reference WTRU, and the server WTRU; and / or one or more of the same actions.

[0068] Location services (LCS) may be performed and / or provided.

[0069] Location services (e.g., 5G location services) can provide the functionality to offer WTRU positioning information.

[0070] WTRU positioning may be supported by a RAT-dependent positioning method that may use (e.g., depend on) RAT measurements obtained by the target WTRU and / or measurements obtained by the access network of the RAT signals transmitted by the target WTRU. WTRU positioning may also be supported by a RAT-independent positioning method that may use (e.g., depend on) non-RAT measurements obtained by the WTRU and / or other information.

[0071] Location information for one or more target WTRUs may be requested and reported to LCS clients, or to AFs within or outside the operator network, or to control plane NFs within the system (e.g., radio systems such as WTRUs).

[0072] Privacy (e.g., settings) verification of the target WTRU may be enabled (e.g., must be enabled) to verify whether WTRU location information can be obtained (e.g., is permitted to be obtained) for location requests from, for example, an LCS client or AF.

[0073] For example, different types of location requests may be supported, such as mobile terminated location requests (MT-LR), mobile originated location requests (MO-LR), immediate location requests, delayed location requests, and / or one or more of the same.

[0074] A Mobile Terminal Location Request (MT-LR) may involve an LCS client or AF sending a location request to the network about the location of a target WTRU.

[0075] A Mobile Outgoing Location Request (MO-LR) may involve a WTRU sending a request for location-related information about the WTRU to the network.

[0076] A location request (e.g., an immediate location request) may include (e.g., an LCS client or AF) sending or triggering a location request about a target WTRU, and the LCS client or AF may (e.g., expect to receive) a response containing location information about the target WTRU within a certain period (e.g., a short period). A location request (e.g., an immediate location request) may be used for MT-LR or MO-LR.

[0077] A delayed location request may involve (for example, an LCS client or AF) sending a location request for a target WTRU to the network, and the LCS client or AF may expect to receive a response when the indicated event occurs for the target WTRU (for example, at a specific time in the future). Delayed location requests may also be used for MT-LR.

[0078] Figure 2 shows an exemplary reference model of a network for location services, where (R)AN may represent (for example, can represent) NG-RAN, trusted (e.g., non-3GPP) access, or untrasted (e.g., non-3GPP) access. The access network may be involved in processing various positioning procedures, such as positioning a target WTRU, provisioning location-related information not associated with a specific target WTRU, and / or forwarding positioning messages between an AMF or LMF and a target WTRU.

[0079] AF and NF can, for example, access LCS services from GMLC within the same operator network.

[0080] LCS clients can access LCS services from GMLC. External AFs can access LCS services from NEFs.

[0081] GMLC (Gateway Mobile Location Centre) can process requests from external LCS clients and AFs, for example, via NEFs (for example, when an AF is an external AF and forwards location requests to the appropriate NF).

[0082] An LRF (Location Retrieval Function) can retrieve or validate location information (for example, be responsible for retrieval or validation) and can be collated with GMLC or standalone.

[0083] LMF can manage the coordination and scheduling of resources (e.g., overall) used (e.g., required) for the location of WTRUs registered with or accessing the core network (e.g., 5GCN). It may also calculate or verify the final location-related information and the accuracy achieved.

[0084] SL positioning (e.g., sidelink-based positioning) services may be enabled, used, and / or provided.

[0085] SL positioning can reference positioning WTRUs (e.g., using PC5) to obtain absolute position, relative position, or ranging information. Ranging can indicate the distance between two or more WTRUs and / or the direction of one WTRU (e.g., target WTRU) from another WTRU (e.g., reference WTRU) via the PC5 interface. Ranging can indicate the distance between two or more WTRUs and / or the direction of one WTRU (e.g., target WTRU) from another WTRU (e.g., reference WTRU) via the PC5 interface.

[0086] For SL positioning, target WTRUs, SL reference WTRUs, SL positioning client WTRUs, and / or positioned WTRUs may be defined (but not limited to) and used as follows: A target WTRU may include a WTRU whose distance, direction, and / or position can be measured with support from one or more SL reference WTRUs using sidelink and sidelink positioning in a distance-based service. A positioned WTRU may include an SL reference WTRU whose location is known or may be known (e.g., using Uu-based positioning). A positioned WTRU may be used, for example, to determine the location of a target WTRU using sidelink positioning. An SL reference WTRU may include a WTRU that supports the positioning of a target WTRU (e.g., by sending and receiving reference signals for positioning) using sidelink to provide positioning-related information, etc. An SL positioning client WTRU can include a third-party WTRU (e.g., something other than an SL reference WTRU or target WTRU) which can initiate ranging / sidelink positioning service requests on behalf of the application residing on it.

[0087] The ranging / sidelink positioning operation can be performed either as a network-assisted operation or as a WTRU-only operation. For example, in network-assisted operation, the core network NF (e.g., 5GC NF) may be involved in service request processing and result calculation. For example, in WTRU-only operation, the service request processing and result calculation operations may be performed by the WTRU.

[0088] LMF (e.g., as defined in Location Services) may be used to support triggering SL positioning, coordinating SL positioning operations, and / or delivering results to clients, for example, when network-assisted operations are used (e.g., at ). Distancing / sidelink positioning service requests can be initiated by WTRUs (e.g., SL positioning client WTRU, target WTRU, SL reference WTRU), core network NFs (e.g., 5GC NFs), LCS clients, and / or AFs.

[0089] WTRUs can interact with each other (e.g., via PC5) to perform SL positioning operations, for example, when WTRU (e.g., WTRU only) operation is used (e.g., at times). SL positioning server WTRUs can be defined to coordinate SL positioning operations and calculate positioning results.

[0090] The SL positioning server WTRU may include a WTRU that provides method determination, assistant data distribution, and / or position calculation functions for sidelink positioning and distance measurement-based services.

[0091] Network-assisted SL positioning may be enabled, performed, and / or provided.

[0092] Network-assisted SL positioning can be used to estimate the position of a WTRU using network assistance by using the location of one or more positioned WTRUs and the distance and / or direction between the WTRUs and the positioned WTRUs.

[0093] The network-assisted SL positioning function may include one or more cases, such as when the WTRU can establish a NAS signaling connection (e.g., at _____) or when the WTRU refrains from establishing a NAS signaling connection (e.g., when it cannot) (e.g., at _____).

[0094] A WTRU can enter the CM-Connected state, for example, by executing a WTRU-triggered Service Request (e.g., 5GC-MO-LR) to the MO-LR, or by executing a Network-triggered Service Request (e.g., 5GC-NI-LR) to the NI-LR, or a Network-triggered Service Request (e.g., 5GC-MT-LR) to the MT-LR, if the WTRU can establish a NAS connection (e.g., when). The functions specified in the location service (including MO-LR, MT-LR, and NI-LR) can be reused, for example, if the target WTRU can establish a NAS signaling connection with the AMF.

[0095] The target WTRU or LMF can be used to determine whether network-assisted SL positioning is applicable.

[0096] The target WTRU can detect a positioned WTRU for network-assisted SL positioning.

[0097] The target WTRU and the positioned WTRU can perform distance measurement / SL positioning. The target WTRU can include WTRU identification information of the positioned WTRU to the LMF, along with distance measurement data or estimation results. The LMF can interact with the GMLC to obtain the position of the positioned WTRU.

[0098] The LMF can estimate the position of the target WTRU using the position of the positioned WTRU along with the distance measurement / SL positioning measurement data or estimation results reported by the target WTRU and / or (for example, optionally) the positioned WTRU.

[0099] If a target WTRU is unable to establish a NAS connection with the AMF due to being out of coverage or for other reasons (e.g., invalid subscription, NW rejection), one or more of the following may apply: the target WTRU can perform detection and selection of a positioned WTRU; the target WTRU can send its ranging measurements / results to the positioned WTRU; the positioned WTRU can report its ranging / SL positioning measurement results to the LMF (e.g., this may include ranging measurements / results received from the target WTRU, and the endpoints of the LPP message may be the LMF and the positioned WTRU); the LMF can use the received information to calculate the position of the target WTRU and provide the resulting position to the target WTRU via the positioned WTRU or to an LCS client or application server via the NF.

[0100] Exposure to SL positioning services to WTRU may be enabled and / or provided.

[0101] A WTRU (e.g., an SL positioning client WTRU) can request SL positioning via PC5 or NW.

[0102] An SL positioning client WTRU can detect one of the reference WTRU and target WTRU. For example, when an SL positioning client UE requests an SL positioning service via a PC5 connection (e.g., at 10:00), it can invoke a distance measurement / SL positioning service request to the detected reference WTRU / target WTRU to obtain the distance measurement between the reference WTRU and target WTRU and the SL positioning result. The request may include user information for the SL positioning client WTRU, the reference WTRU, and / or the target WTRU.

[0103] The SL positioning service operation by the LMF or SL positioning server WTRU can be performed, for example, based on (e.g., after) receiving an SL positioning service request.

[0104] The SL positioning server WTRU can collaborate with the LMF (for example, for an SL positioning service) to better support SL positioning between a target WTRU and an SL reference WTRU.

[0105] For example, for out-of-coverage or WTRU-only operation (e.g., when the serving network does not support ranging / SL positioning), an SL positioning server WTRU can be discovered and selected for result calculation, method determination, support data distribution, and / or SL reference UE selection. For example, if an LMF capable of ranging / SL positioning is reachable by a target WTRU and / or a reference WTRU, the LMF can determine that an SL positioning server WTRU (e.g., one that is co-located / integrated with the target WTRU or reference WTRU) can perform result calculations. An SL positioning server WTRU can be co-located with a target WTRU or a reference WTRU.

[0106] The LMF can recognize available SL positioning server WTRUs within its service area (for example, it can be assumed that the LMF can recognize available SL positioning server WTRUs within its service area (for example, based on the above)). There may be one or more SL positioning server WTRUs per service area. Coordination between the LMF and the SL positioning server WTRUs may not be clear.

[0107] The quality of service of SL positioning service operations may not be as good as that provided by LMF, for example, if an SL positioning server WTRU is involved in the coordination of SL positioning operations (e.g., at times), because resources used by WTRUs based on the coordination of SL positioning servers may be shared among many WTRUs performing SL positioning operations, and the configuration for SL positioning operations may be based on pre-configured parameters that are more likely to conflict with other similar operations. In such cases, such conflicts can be avoided.

[0108] The SL positioning server WTRU can assist (e.g., provide better assistance) with SL positioning between the target WTRU and the SL reference WTRU, for example, if the LMF is aware of the SL positioning server WTRU.

[0109] The SL positioning server WTRU can assist the SL positioning client WTRU in selecting the SL reference WTRU for the SL positioning service.

[0110] For example, if an LMF capable of ranging / SL positioning (as described herein) is reachable by a target WTRU and / or reference WTRU, the LMF can determine that an SL positioning server WTRU (e.g., one co-located / integrated with the target WTRU or reference WTRU) can perform the result calculation. Whether (e.g., when) the LMF will transfer the positioning service operation to the server WTRU may not be clear.

[0111] An SL positioning server WTRU can perform coordination, for example, between peer WTRUs (e.g., between an SL reference WTRU and / or between an SL client WTRU and an SL reference WTRU), thus gaining better knowledge about nearby available SL reference WTRUs. This information can be used to support the operation of positioning services that may be provided by the server WTRU.

[0112] The SL positioning server WTRU can interact with the LMF to receive support data available to the LMF (for example, which can be used to improve positioning services within the service area of ​​the positioning server).

[0113] The SL positioning server WTRU can assist the SL positioning client WTRU in selecting an SL reference WTRU for the SL positioning service.

[0114] A WTRU can be one or more of the following: client WTRU, SL client WTRU, reference WTRU, SL reference WTRU, SL positioning reference WTRU, server WTRU, positioning server WTRU, SL server WTRU, SL positioning server WTRU, etc.

[0115] The terms SL client WTRU and client WTRU (as described herein, for example) may be used interchangeably.

[0116] The terms SL positioning reference WTRU, SL reference WTRU, and reference WTRU (as described herein, for example) may be used interchangeably.

[0117] The terms SL positioning server WTRU, SL server WTRU, positioning server WTRU, and server WTRU may be used interchangeably (for example, as described herein).

[0118] WTRU may support PC5 signaling (for example, it can be assumed to support it). PC5 signaling may be supported by the ProSe layer within the WTRU.

[0119] A WTRU (for example, as described herein) may have ranging and sidelink positioning capabilities, and / or sidelink positioning server WTRU capabilities. Sidelink positioning may represent positioning via the PC5 interface, and ranging may represent the determination of the distance between two or more WTRUs and / or the direction and / or relative positioning of one WTRU to another WTRU.

[0120] SL positioning operations involving one or more interactions between the LMF and the SL positioning server WTRU may be performed, enabled, and / or provided.

[0121] A WTRU, such as a positioning server WTRU, can receive policy configuration information from the NF (e.g., a PCF, which may be specific to the SL positioning server WTRU based on its capabilities and subscription information) (e.g., when registering with the network). The SL positioning server can notify the LMF of its capabilities as a server WTRU and share the received policy configuration information (e.g., some or all of it). The LMF can request a PCF (e.g., also request a PCF) if there are updates to the policy linked to the SL positioning server WTRU.

[0122] The LMF may transmit a list of positioned SL reference WTRUs within its area (based on input received from, for example, the SL positioning server WTRU, its service area, and / or location). The LMF may transmit a resource pool (e.g., a general resource pool) and / or any supporting data (e.g., any) that may be useful to the server WTRU in the operation of the positioning service, per server WTRU or per service area.

[0123] The positioning server WTRU can use this input (e.g., from the LMF) to assist the target WTRU, based on receiving a positioning service request from either the target WTRU or an SL reference WTRU. The SL positioning server may receive further information as part of the SL positioning service request, which can assist the server WTRU in determining the positioning method and selecting the SL reference WTRU. The positioning server WTRU can cooperate with the LMF in the decision process (e.g., if necessary).

[0124] Figure 3 illustrates an exemplary procedure for SL positioning operation involving one or more interactions between the LMF and the SL positioning server WTRU.

[0125] As shown in Figure 3, 310, the SL positioning server WTRU (which may be, for example, a target WTRU or an SL reference WTRU) may receive configuration information from the NF (for example, the PCF of the SL positioning server WTRU) to support the SL positioning service (for example, the configuration information may be associated with SL positioning support). The configuration information may also be provided by the AF for ranging / positioning (for example, similarly).

[0126] In the example, authentication and authorization (e.g., mutual authentication and authorization) may be performed (e.g., should be performed). Evidence of authorization (e.g., authorization token) may be issued (e.g., should be issued) to the SL positioning server WTRU (e.g., by the network).

[0127] As shown in Figure 3320, the SL positioning server WTRU can send positioning service messages (e.g., indicating capability information, e.g., indicating the ability to function as a positioning server WTRU) to network entities such as the LMF, which may include the ability to perform some or all of the actions supported as a positioning server WTRU (e.g., result calculation, method determination, support data distribution, and / or SL reference WTRU selection).

[0128] As shown in Figure 330, an SL positioning server WTRU may receive (e.g., from a network entity / LMF) a list of positioned SL reference WTRUs (e.g., a candidate list of SL reference WTRUs) that may be available based on the server WTRU's location or service area. The SL positioning server WTRU may share a list of other nearby SL server WTRUs, along with their supported capabilities. The definition of an area can be determined by the LMF and may be, for example, a broad area such as a TA, the LMF's service area, or a more concentrated area immediately adjacent to the server WTRU.

[0129] As shown in Figure 3, 340, the SL positioning server WTRU may be allocated a general / general-purpose resource pool per area for SL positioning operations, or a different resource pool per SL positioning server WTRU, by the LMF, for example, if there are multiple WTRUs sharing the same area.

[0130] A target WTRU or SL reference WTRU can initiate an SL positioning request (e.g., an SL positioning request associated with the target WTRU, an SL positioning request indicating a first WTRU and / or a second WTRU), which may include, for example, information on at least one or a list of SL reference WTRUs detected by the WTRU (e.g., WTRU ID, status information (e.g., NAS / non-NAS), capability), target WTRU information, and / or positioning information (e.g., requirements). An SL positioning service request may be determined, for example, by an SL positioning server WTRU (e.g., which may be colocated with the target WTRU or SL reference WTRU, or which may be the target WTRU or SL reference WTRU).

[0131] The positioning service information (e.g., positioning method and / or SL reference WTRU) may be determined (e.g., selected) as shown in 350a and 350b of Figure 3.

[0132] As shown in Figure 350a, the SL positioning server WTRU can determine positioning service information (e.g., positioning method and / or SL reference WTRU) (e.g., the information itself) based on configuration information received from, for example, an NF (e.g., PCF, LMF) or AF, and input from the WTRU for ranging / positioning. The SL positioning server WTRU can select one or more SL reference WTRUs and choose their availability for distribution of supporting data and / or result calculations.

[0133] As shown in 350b of Figure 3, the SL positioning server WTRU may communicate with the LMF (for example, one or more messages exchanged between the server WTRU and the LMF, which may be sent to the LMF when a positioning requirement is received by the server WTRU) to request additional support data or better resource allocation from the LMF before performing the action in 350a for the selection of an SL positioning method.

[0134] For example, as shown in 360 of Figure 3 (for example, if 350a is true), an SL positioning server WTRU can request dedicated radio resources from the LMF for the requested positioning service (for example, if high-precision positioning is desired), and there are many WTRUs requesting positioning services from the SL positioning server WTRU, which can lead to message collisions.

[0135] As shown in Figures 370a and 370b, the SL positioning server can transmit one or more of the following:

[0136] As shown in Figure 370a, the SL positioning server can send a message (e.g., an SL positioning response message) to the target WTRU via the PC5 link, which may include positioning information (e.g., a selected positioning method and / or SL reference WTRU), and can select the SL reference WTRU ID and the assigned radio resource.

[0137] As shown in Figure 3, 370b, the SL positioning server can send a message to the SL reference WTRU that may include the selected positioning method, the respective target WTRU ID, and / or the assigned radio resources (e.g., an indication if selected as the SL reference WTRU for positioning assistance with the target WTRU).

[0138] In the example (for example, at 350 in Figure 3), the SL positioning server WTRU may pass the request to another server WTRU (for example, based on capacity and load). In the example (for example, alternatively), the selection of the SL positioning server WTRU may be made by the SL positioning server itself or with assistance from the LMF. In this procedure, based on a positioning service request from the SL positioning client WTRU (for example, when a request is made), the server WTRU may reroute this request to another server WTRU itself, or may ask the LMF to suggest another server ID that may be capable of handling the positioning request from the client WTRU. The current server WTRU may be in a situation where it is unable to handle the request from the client WTRU.

[0139] Although the features and elements described above are described in specific combinations, each feature or element may be used alone without other features and elements of the preferred embodiment, or in various combinations with or without other features and elements.

[0140] While the implementations described herein may take into account 3GPP-specific protocols, it should be understood that the implementations described herein are not limited to these scenarios and may be applicable to other wireless systems. For example, while the solutions described herein may take into account LTE, LTE-A, New Radio (NR), or 5G-specific protocols, it should be understood that the solutions described herein are not limited to these scenarios and may be applicable to other wireless systems.

[0141] The above processes may be executed by computer programs, software, and / or firmware embedded in computer-readable media for execution by a computer and / or processor. Examples of computer-readable media include, but are not limited to, electronic signals (transmitted via wired and / or wireless connections) and / or computer-readable storage media. Examples of computer-readable storage media include, but are not limited to, read-only memory (ROM), random access memory (RAM), registers, cache memory, semiconductor memory devices, magnetic media (such as, but not limited to, internal hard disks and removable disks), magneto-optical media, and / or optical media (such as CD-ROM discs and / or digital multipurpose discs (DVDs)). Processors combined with software may be used to implement radio frequency transceivers used in WTRUs, terminals, base stations, RNCs, or any host computer.

Claims

1. A wireless transceiver unit (WTRU) equipped with a processor, The aforementioned processor, Receiving configuration information associated with SideLink (SL) positioning assistance, Sending a positioning service message indicating capability information to a network entity, wherein the capability information indicates that the WTRU can function as an SL positioning server WTRU. To determine the SL positioning service request associated with the target WTRU, Determining location positioning service information associated with a location positioning service, wherein the location positioning service is associated with the target WTRU, and the location positioning service information includes at least one of a location positioning method and an SL reference WTRU. The SL positioning response indicating the determined positioning service information is transmitted to the target WTRU. WTRU is configured to execute.

2. The aforementioned processor, A WTRU according to claim 1, further configured to receive a message from the network entity containing a list of candidates for an SL reference WTRU, wherein the SL reference WTRU is from the list of candidates for an SL reference WTRU.

3. The SL positioning service request is a WTRU according to claim 1, which indicates at least one of the target WTRU ID, reference WTRU information, and positioning requirement information.

4. The WTRU is a sidelink positioning server WTRU according to claim 1.

5. The WTRU according to claim 1, wherein the WTRU is the target WTRU or the SL reference WTRU.

6. The SL reference WTRU is associated with at least one of a location or a service area, according to claim 1.

7. The WTRU of claim 1, wherein the determination of the positioning service information associated with the positioning service associated with the target WTRU is performed based on at least one of the received configuration information associated with SL positioning assistance and the indication received from the network entity.

8. The WTRU of claim 1, wherein the target WTRU is a first WTRU, and the SL positioning service request indicates the first WTRU and the second WTRU.

9. Receiving configuration information associated with SideLink (SL) positioning assistance, The method involves transmitting a positioning service message indicating capability information to a network entity, wherein the capability information indicates that the wireless transceiver unit (WTRU) can function as an SL positioning server WTRU. To determine the SL positioning service request associated with the target WTRU, Determining location positioning service information associated with a location positioning service, wherein the location positioning service is associated with the target WTRU, and the location positioning service information includes at least one of a location positioning method and an SL reference WTRU. The SL positioning response indicating the determined positioning service information is transmitted to the target WTRU. A method that includes this.

10. The aforementioned method, The method of claim 9, further comprising receiving a message from the network entity containing a candidate list of SL reference WTRUs, wherein the SL reference WTRUs are from the candidate list of SL reference WTRUs.

11. The method of claim 9, wherein the SL positioning service request indicates at least one of the target WTRU ID, reference WTRU information, and positioning requirement information.

12. The method of claim 9, wherein the method is performed by the WTRU, the WTRU is a sidelink positioning server WTRU.

13. The method of claim 9, wherein the method is performed by the WTRU, the WTRU is the target WTRU or the SL reference WTRU.

14. The method of claim 9, wherein the SL reference WTRU is associated with at least one of a location or a service area.

15. The method of claim 9, wherein the determination of the positioning service information associated with the positioning service associated with the target WTRU is performed based on at least one of the received configuration information associated with SL positioning assistance and the indication received from the network entity.

16. The method of claim 9, wherein the target WTRU is a first WTRU, and the SL positioning service request indicates the first WTRU and the second WTRU.

Images