WO2024093050A1

WO2024093050A1 - Terminal device and method for positioning

Info

Publication number: WO2024093050A1
Application number: PCT/CN2023/076551
Authority: WO
Inventors: Jie Hu; Jing HAN; Haiming Wang; Lihua Yang; Luning Liu
Original assignee: Lenovo (Beijing) Limited
Priority date: 2023-02-16
Filing date: 2023-02-16
Publication date: 2024-05-10

Abstract

Embodiments of the present disclosure relate to a solution for positioning supporting SLPP. In one aspect of the solution, a first terminal device receives first information including a first SL-PRS configuration from a second terminal device. The first terminal device transmits feedback information indicating whether the first SL-PRS configuration is accepted to the second terminal device. As such, a behavior at the first terminal device is defined in case a configuration confliction occurs. Through the proposed solution, the second terminal device may be aware of whether a first SL-PRS configuration is accepted at the first terminal device. Accordingly, the second terminal device may perform further operation if the first SL-PRS configuration is not accepted and a sidelink positioning may be guaranteed.

Description

TERMINAL DEVICE AND METHOD FOR POSITIONING

FIELD

Embodiments of the present disclosure generally relate to the field of communication, and in particular to a terminal device and a method for positioning.

BACKGROUND

A long term evolution (LTE) positioning protocol (LPP) session is used between a location server and a target device in order to obtain location related measurements or a location estimate or transfer assistance data. For example, the LPP session involves a terminal device and a location management function (LMF) .

A sidelink (SL) positioning protocol (SLPP) involves multiple terminal devices, such as one target terminal device, one server terminal device, and one or more anchor terminal devices. A terminal device may be involved in more than one SLPP session, and a further study on SLPP is still needed.

SUMMARY

In general, embodiments of the present disclosure provide a solution for positioning by enhancements of supporting a sidelink positioning protocol.

In a first aspect, there is provided a first terminal device. The first terminal device comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to: receive, via the transceiver, from a second terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration; determine feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device; and transmit, via the transceiver, to the second terminal device, the feedback information.

In a second aspect, there is provided a second terminal device. The second terminal device comprises a processor and a transceiver coupled to the processor, wherein the processor is configured to: transmit, via the transceiver, to a first terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration; and receive, via the transceiver, from the first terminal device, feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device.

In a third aspect, there is provided a method performed by a first terminal device. The method comprises: receiving, from a second terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration; determining feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device; and transmitting, to the second terminal device, the feedback information.

In a fourth aspect, there is provided a method performed by a second terminal device. The method comprises: transmitting, to a first terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration; and receiving, from the first terminal device, feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device.

In a fifth aspect, there is provided a computer readable medium. The computer readable medium has instructions stored thereon. The instructions, when executed on at least one processor of a device, causing the device to perform the method of the third or fourth aspect.

It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments will now be described with reference to the accompanying drawings, in which:

FIGS. 1A-1G illustrate some example procedures of LPP;

FIG. 2 illustrates an example scenario of sidelink positioning involving multiple SLPP sessions;

FIG. 3 illustrates a schematic diagram of a communication environment in which some embodiments of the present disclosure can be implemented ;

FIG. 4 illustrates an example of a process flow in accordance with some example embodiments of the present disclosure;

FIG. 5 illustrates another example of a process flow in accordance with some example embodiments of the present disclosure;

FIG. 6 illustrates an example of a process flow that an SLPP session supports only one positioning service in accordance with some example embodiments of the present disclosure;

FIG. 7 illustrates an example of a process flow that an SLPP session supports multiple positioning services in accordance with some example embodiments of the present disclosure;

FIG. 8 illustrates an example of a process flow of session abortion in accordance with some example embodiments of the present disclosure;

FIG. 9 illustrates a flowchart of an example method performed by a first terminal device in accordance with some embodiments of the present disclosure;

FIG. 10 illustrates a flowchart of an example method performed by a second terminal device in accordance with some embodiments of the present disclosure; and

FIG. 11 illustrates a simplified block diagram of an apparatus that is suitable for implementing embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar elements.

DETAILED DESCRIPTION

Principles of the present disclosure will now be described with reference to some embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below. In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an example embodiment, ” “an embodiment, ” “some embodiments, ” and the like indicate that the embodiment (s) described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment (s) . Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” or the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, a first element could also be termed as a second element, and similarly, a second element could also be termed as a first element, without departing from the scope of embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms. In some examples, values, procedures, or apparatuses are referred to as “best, ” “lowest, ” “highest, ” “minimum, ” “maximum, ” or the like. It will be appreciated that such descriptions are intended to indicate that a selection among many used functional alternatives can be made, and such selections need not be better, smaller, higher, or otherwise preferable to other selections.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of embodiments. As used herein, the singular forms “a, ” “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises, ” “comprising, ” “has, ” “having, ” “includes” and/or “including, ” when used herein, specify the presence of stated features, elements, components and/or the like, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. For example, the term “includes” and its variants are to be read as open terms that mean “includes, but is not limited to. ” The term “based on” is to be read as “based at least in part on. ” The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment. ” The term “another embodiment” is to be read as “at least one other embodiment. ” The use of an expression such as “A and/or B” can mean either “only A” or “only B” or “both A and B. ” Other definitions, explicit and implicit, may be included below.

As used herein, the term “communication network” refers to a network following any suitable communication standards, such as, 5G NR, Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) , and so on. Further, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the fifth generation (5G) , the sixth generation (6G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will also be future type communication technologies and systems in which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned systems.

As used herein, the term “network device” generally refers to a node in a communication network via which a terminal device can access the communication network and receive services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a node B (NodeB or NB) , a radio access network (RAN) node, an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a Remote Radio Unit (RRU) , a radio header (RH) , an infrastructure device for a V2X (vehicle-to-everything) communication, a transmission and reception point (TRP) , a reception point (RP) , a remote radio head (RRH) , a relay, an integrated access and backhaul (IAB) node, a low power node such as a femto BS, a pico BS, and so forth, depending on the applied terminology and technology.

As used herein, the term “terminal device” generally refers to any end device that may be capable of wireless communications. By way of example rather than a limitation, a terminal device may also be referred to as a communication device, a user equipment (UE) , an end user device, a subscriber station (SS) , an unmanned aerial vehicle (UAV) , a portable subscriber station, a mobile station (MS) , or an access terminal (AT) . The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable terminal device, a personal digital assistant (PDA) , a portable computer, a desktop computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and playback appliance, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , a USB dongle, a smart device, wireless customer-premises equipment (CPE) , an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD) , a vehicle, a drone, a medical device (for example, a remote surgery device) , an industrial device (for example, a robot and/or other wireless devices operating in an industrial and/or an automated processing chain contexts) , a consumer electronics device, a device operating on commercial and/or industrial wireless networks, and the like. In the following description, the terms: “terminal device, ” “communication device, ” “terminal, ” “user equipment” and “UE, ” may be used interchangeably.

As used herein, the term: “resource, ” “transmission resource, ” “resource block, ” “physical resource block, ” “uplink resource, ” “downlink resource, ” or “sidelink resource” may refer to any resource, for example a resource in time domain, a resource in frequency domain, a resource in space domain, a resource in code domain, or any other resource enabling a communication, and the like, used for performing a communication between a terminal device and a network device or between terminal devices. In the following, a resource in both frequency and time domain will be used as an example of a transmission resource for describing some embodiments of the present disclosure. It is noted that embodiments of the present disclosure equally apply to other resources in other domains.

As mentioned above, an LPP session involves only a terminal device (such as a UE) and an LMF, and an LPP signalling message is transmitted between the UE and the LMF. A single LPP session is used to support a single location request, e.g., for a single mobile terminal –location request (MT-LR) , mobile originating –location request (MO-LR) , or network induced –location request (NI-LR) . Multiple LPP sessions can be used between the same endpoints to support multiple different location requests. Each LPP session comprises one or more LPP transactions, with each LPP transaction performing a single operation (capability exchange, assistance data transfer, or location information transfer) . In evolved universal terrestrial radio access (E-UTRAN) and next generation radio access network (NG-RAN) , the LPP transactions are realized as LPP procedures. The instigator of an LPP session will always instigate the first LPP transaction, but subsequent transactions may be instigated by either end. LPP transactions within a session may occur serially or in parallel. LPP transactions are indicated at the LPP protocol level with a transaction identifier (ID) in order to associate messages with one another (e.g., request and response) . Messages within a transaction are linked by a common transaction identifier.

The LPP operates between a "target" and a "server" . A procedure may be initiated by either the target or the server. Both target initiated and server initiated procedures are supported.

Capabilities refer to the ability of a target or server to support different position methods defined for LPP, different aspects of a particular position method (e.g. different types of assistance data for A-GNSS) and common features not specific to only one position method (e.g. ability to handle multiple LPP transactions) . These capabilities are defined within the LPP protocol and transferred between the target and the server using LPP transport. The exchange of capabilities between a target and a server may be initiated by a request or sent as "unsolicited" information.

FIG. 1A illustrates an LPP capability transfer procedure 110, if a request is used. As shown in FIG. 1A, the server sends an LPP Request Capabilities message to the target device with a request for capability information, at step 1. The target sends an LPP Provide Capabilities message, at step 2. FIG. 1B illustrates an LPP capability indication procedure 120 for unsolicited capability transfer. As shown in FIG. 1B, the target sends an LPP Provide Capabilities to the server.

Assistance data may be transferred either by request or unsolicited. For example, assistance data delivery may be supported only via unicast transport from server to target.

FIG. 1C illustrates an LPP assistance data transfer procedure 130 by request. The procedure 130 includes steps 1-2 and optionally step 3. Step 1: The target may send a request (i.e., LPP Request Assistance Data in FIG. 1C) to the server for assistance data and may indicate the particular assistance data needed. Step 2: The server transfers assistance data (i.e., LPP Provide Assistance Data in FIG. 1C) to the target. The transferred assistance data should match any assistance data requested in step 1. Step 3: Optionally, the server may transfer additional assistance data to the target in one or more additional LPP messages. FIG. 1D illustrates an LPP assistance data delivery procedure 140 for unilateral assistance data transfer. As shown in FIG. 1D, the server sends an LPP Provide Assistance Data to the target.

The term "location information" applies both to an actual position estimate and to values used in computing position (e.g., radio measurements or positioning measurements) . It is delivered either in response to a request or unsolicited.

FIG. 1E illustrates an LPP location information transfer procedure 150 by request. The procedure 150 includes steps 1-2 and optionally step 3. Step 1: The server may send a request (i.e., LPP Request Location Information in FIG. 1E) for location information to the target, and may indicate the type of location information needed and associated QoS. Step 2: In response to step 1, the target transfers location information (i.e., LPP Provide Location Information in FIG. 1E) to the server. The location information transferred should match the location information requested in step 1. Step 3: Optionally (e.g., if requested in step 1) , the target in step 2 may transfer additional location information to the server in one or more additional LPP messages. FIG. 1F illustrates an LPP location information delivery procedure 160 for unilateral location information transfer. As shown in FIG. 1F, the target sends an LPP Provide Location Information to the server. It is noted that the LPP location information delivery procedure 160 can only be piggybacked in the MO-LR request.

FIG. 1G illustrates a procedure 170 for notifying the other endpoint by one endpoint to abort an ongoing procedure between the two endpoints. This procedure 170 is bidirectional at the LPP level; either the target or the server may take the role of either endpoint. As shown in FIG. 1G, an LPP procedure is ongoing between target and server, at step 1. If the server or target ( "Server/Target" ) determines that the procedure must be aborted, and then the server or target sends an LPP Abort message to the other endpoint ( "Target/Server" ) carrying the transaction ID for the procedure, at step 2.

As mentioned above, the SLPP may involve multiple terminal devices, for example, including a target user equipment (T-UE) , a server user equipment (S-UE) , and one or more anchor user equipment (A-UE) . With regards to the sidelink positioning procedures between UEs, SLPP is introduced to support at least the following functionalities:

● SL Positioning Capability Transfer,

● SL Positioning Assistance Data exchange,

● SL Location Information Transfer,

● Error handling,

● Abort.

The cast type for SLPP signalling is studied, including unicast, groupcast and broadcast. Unicast/one-to-one operation is assumed as baseline for exchange of SLPP signaling between UEs. Unicast SLPP session-based operation is supported. At least “centralized” operation is supported, i.e., operation where one UE performs range and/or position calculations based on measurement/location information relating to itself and/or other UEs. It is feasible to send at least the following positioning signaling for groupcast/broadcast (in addition to unicast) from RAN2’s perspective:

● SL positioning capability,

● SL positioning assistance data.

Location information is not excluded and can be further considered in normative work. Both session-based and session-less operation for sidelink positioning signaling are studied. Sidelink positioning supports a session-based concept in SLPP, in which signaling messages within a session can be associated with one another by the involved UEs. The relationship to upper-layer designs from SA2 can be discussed during normative work.

If the same principles in LPP are reused in SLPP, it is straightforward that an SLPP session is used for supporting a single location request and multiple SLPP sessions may be used for supporting multiple location requests. FIG. 2 illustrates an example scenario 200 of sidelink positioning involving multiple SLPP sessions. As shown in FIG. 2, there are three sessions, where a session 210 (also be referred to as session 1) involves T-UE 1, S-UE 1, and A-UE 1 to 3, a session 220 (also be referred to as session 2) involves T-UE 2, S-UE 2, and A-UE 2 to 4, a session 230 (also be referred to as session 3) involves T-UE 1, S-UE 2 and A-UE 2 to 3.

Session 210 targets for location request 1 of T-UE1, in which S-UE1 is the server UE for T-UE1, A-UE1/2/3 are the anchor UEs for T-UE1. S-UE1/T-UE1 provides assistance data to A-UE1/2/3, A-UE1/2/3 transmit SL-PRS to T-UE1 then T-UE1 transmits measurement results to S-UE1, or T-UE1 transmits SL-PRS to A-UE1/2/3 and then A-UE1/2/3 provides measurement results to T-UE1/S-UE1.

Session 220 targets to location request 2 of T-UE2, in which S-UE2 is the server UE for T-UE2, A-UE 2/3/4 are the anchor UEs for T-UE2. S-UE2/T-UE2 provides assistance data to A-UE2/3/4, A-UE2/3/4 transmits SL-PRS to T-UE2 then T-UE2 transmits measurement results to S-UE2, or T-UE2 transmits SL-PRS to A-UE 2/3/4 and then A-UE 2/3/4 provides measurement results to T-UE2/S-UE2.

Session 230 targets to location request 3 of T-UE1, in which S-UE1 is the server UE for T-UE1, A-UE2/3 are the anchor UEs for T-UE1. S-UE1/T-UE1 provides assistance data to A-UE2/3, A-UE 2/3 transmit SL-PRS to T-UE1 then T-UE1 transmits measurement results to S-UE1, or T-UE1 transmits SL-PRS to A-UE 2/3 and then A-UE2/3 provides measurement results to T-UE1/S-UE1.

However, there are some different issues on the sidelink positioning procedures based on UE type in SLPP sessions. For example, one anchor UE serves for multiple location requests/SLPP sessions, the same anchor UE (e.g., A-UE2/UE-3 in FIG. 2) involves in multiple SLPP sessions (e.g., session 1/2/3) managed by or connected to different target UEs/server UEs (S-UE1/T-UE1 and S-UE2/T-UE2) or same target UEs/server UEs (S-UE1/T-UE1) . For example, one target UE or server UE involves in multiple location requests/SLPP sessions, e.g., for the same target UE or server UE T-UE1/S-UE1 in FIG. 2, A-UE1/A-UE2/A-UE3 are served for location request 1, A-UE2/A-UE3 are served for location request 3.

In the case of the same anchor UE (e.g., A-UE2, A-UE3 in FIG. 2) is involved in multiple location requests which managed by different target UEs or server UEs (T-UE1/S-UE1 and T-UE2/S-UE2) , those different target UEs or target UEs may generate similar requirements or provide conflicted configuration to the anchor UEs, which may lead to ambiguous behaviors from anchor UE sides. In the case of one target UE or server UE initiates multiple location requests, e.g., for T-UE1/S-UE1 in FIG. 2, A-UE1/A-UE2/A-UE3 are served for location request 1, A-UE2/A-UE3 are served for location request 3. Since the involved UEs for location requests 1 and 3 are overlapped, either a common session among the UEs or dedicated SLPP session for each location requests can be reconsidered. While an SLPP session may include one S-UE, one T-UE, and one or multiple A-UEs, the signaling message within an SLPP session can be associated with one another by the involved UEs. Then how to determine the SLPP session is terminated or aborted should be specified considering one SLPP session involves multiple SLPP unicast connection.

In order to solve the above-identified technical problems as well as potentially other technical problems found in the traditional solutions, embodiments of the present disclosure provide a solution for supporting SLPP session (s) for sidelink positioning. In one aspect of the solution of the present disclosure, a first terminal device (e.g. A-UE1, A-UE2, or A-UE3, as shown in FIG. 2) receives first information including a first SL-PRS configuration from a second terminal device (e.g. S-UE1, T-UE1, S-UE2, or T-UE2, as shown in FIG. 2) . The first terminal device transmits feedback information indicating whether the first SL-PRS configuration is accepted to the second terminal device. As such, a behavior at the first terminal device is defined in case a configuration confliction occurs. Through the proposed solution, the second terminal device may be aware of whether a first SL-PRS configuration is accepted at the first terminal device. Accordingly, the second terminal device may perform further operation if the first SL-PRS configuration is not accepted and a sidelink positioning shall be guaranteed. Principles and implementations of embodiments of the present disclosure will be described in detail below with reference to the figures.

EXAMPLE ENVIRONMENT

FIG. 3 illustrates a schematic diagram of a communication environment 300 in which some embodiments of the present disclosure can be implemented. As shown in FIG. 3, the communication environment 300, which may also be referred to as a communication network 300 or a communication system 300, includes a network device 350, a terminal device 310-1, a terminal device 310-2, a terminal device 320-1, a terminal device 320-2 and a terminal device 330. The network device 350 may serve the terminal device 320-1 as shown in FIG. 3, but it is to be understood that the network device 10 may also serve one or more other terminal devices, which will be discussed herein.

In particular, as illustrated in the exemplary scenario of FIG. 3, the terminal device 320-1 may communicate with the network device 350 via a communication link. For transmissions from the network device 350 to the terminal device 320-1, the communication link may be referred to as a downlink (DL) , whereas for transmissions from the terminal device 320-1 to the network device 350, the communication link may alternatively be referred to as an uplink (UL) .

In addition to the communication between a terminal device and a network device, two different terminal devices can perform a sidelink transmission, which is also referred to as a device-to-device (D2D) communication. In some embodiments, the sidelink transmission may be performed in an unlicensed band in which various wireless devices based on different wireless technologies share the same wireless spectrum.

As used herein, the term “sidelink transmission” generally refers to any transmission performed from one terminal device to another terminal device. The sidelink transmission may be used for transmitting any data or control information associated with sidelink communications, for example, sidelink data, sidelink control information, sidelink feedback information, or the like. As used herein, the term “sidelink channel” may generally refer to any channel used for sidelink communications, for example, Physical Sidelink Shared Channel (PSSCH) , Physical Sidelink Control Channel (PSCCH) , Physical Sidelink Discovery Channel (PSDCH) , Physical Sidelink Broadcast Channel (PSBCH) , Physical Sidelink Feedback Channel (PSFCH) , and other existing or future sidelink channels.

As illustrated in FIG. 3, it is assumed that the terminal device 320-1 is a target UE, the terminal device 320-2 is a server UE, and the terminal devices 310-1 and 310-2 are anchor UEs. In some examples, the server UE may be a logical entity, for example, the server UE may be the same as the target UE, or the server UE may be part of an anchor UE. In some examples, the server UE may be implanted as a roadside unit (RSU) . In some examples, the terminal device 310-1 and the terminal device 310-2 may collectively or separately be referred to as a terminal device 310, the terminal device 320-1 and the terminal device 320-2 may collectively or separately be referred to as a terminal device 320.

As illustrated in FIG. 3, a terminal device 330 is further shown, which may be communicated with the terminal device 310-1 and the terminal device 310-2. In some examples, the terminal device 330 may be a target terminal device or a server terminal device different from the terminal device 320.

In some embodiments, the network device 350 may be absent in the communication environment 300.

Although the network device 350 and the terminal devices 310, 320, 330 are described in the communication environment 300 of FIG. 3, embodiments of the present disclosure may equally apply to any other suitable communication devices in communication with one another. That is, embodiments of the present disclosure are not limited to the exemplary scenarios of FIG. 3. In this regard, it is noted that although the network device 350 is schematically depicted as a base station and the terminal devices 310, 320, and 330 are schematically depicted as mobile phones in FIG. 3, it is understood that these depictions are exemplary in nature without suggesting any limitation. In other embodiments, the network device 350 and the terminal devices 310, 320, and 330 may be any other communication devices, for example, any other wireless communication devices.

It is to be understood that the particular number of various communication devices, the particular number of various communication links, and the particular number of other elements as shown in FIG. 3 is for illustration purpose only without suggesting any limitations. The communication environment 300 may include any suitable number of communication devices, any suitable number of communication links, and any suitable number of other elements adapted for implementing embodiments of the present disclosure. In addition, it should be appreciated that there may be various wireless as well as wireline communications (if needed) among all of the communication devices.

Communication in the communication environment 300 may be implemented according to any proper communication protocol (s) , comprising but not limited to, cellular communication protocols of the first generation (1G) , the second generation (2G) , the third generation (3G) , the fourth generation (4G) and the fifth generation (5G) , NR-U and the like, wireless local network communication protocols such as Institute for Electrical and Electronics Engineers (IEEE) 802.11 and the like, and/or any other protocols currently known or to be developed in the future. Moreover, such communication may utilize any appropriate wireless communication technology, comprising but not limited to: Code Division Multiple Access (CDMA) , Frequency Division Multiple Access (FDMA) , Time Division Multiple Access (TDMA) , Frequency Division Duplex (FDD) , Time Division Duplex (TDD) , Multiple-Input Multiple-Output (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

EXAMPLE PROCESS

FIG. 4 illustrates an example of a process flow 400 in accordance with some example embodiments of the present disclosure. The process flow 400 involves a first terminal device 401 and a second terminal device 402. For the purpose of discussion, the first terminal device 401 may be referred to as an anchor UE, such as A-UE 1, A-UE 2, or A-UE 3 as shown in FIG. 2, such as the terminal device 310-1, or the terminal device 310-2 as shown in FIG. 3. For the purpose of discussion, the second terminal device 402 may be referred to as a target UE or a server UE, such as T-UE 1, S-UE 1, T-UE 2, or S-UE 2 as shown in FIG. 2, such as the terminal device 320-1, the terminal device 320-2, or the terminal device 330 as shown in FIG. 3. It would be appreciated that the process flow 400 may be applied to the network environment 300 of FIG. 3 or other communication scenarios.

In the process flow 400, the second terminal device 402 transmits 410 first information 412 to the first terminal device 401. Accordingly, the first terminal device 401 receives 414 the first information 412. In some example embodiments, the first information 412 may include a first SL-PRS configuration.

For example, the first SL-PRS configuration may be associated with one or more positioning services at the second terminal device 402. In some examples, a positioning service may be also referred to as a location service, a positioning service request, a location service request, a positioning request, a location request, or the like, the present disclosure does not limit this aspect.

In the process flow 400, the first terminal device 401 determines 415 feedback information of the first information. In some examples, the first terminal device 401 may determine whether to accept the first SL-PRS configuration. For example, the first terminal device 401 may decide to accept the first SL-PRS configuration. For example, the first terminal device 401 may decide not to accept (i.e., reject) the first SL-PRS configuration. In some examples, the first terminal device 401 may generate the feedback information which indicates whether the first SL-PRS configuration is accepted or not at the first terminal device 401.

The first terminal device 401 transmits 420 feedback information 422 to the second terminal device 402, and the second terminal device 402 receives 424 the feedback information 422.

In some examples, the first information 412 and the feedback information 422 may be transmitted over a sidelink between the first terminal device 401 and the second terminal device 402 unicast.

In some example embodiments, the first information 412 may be assistance data. For example, the assistance data may be associated with an SLPP session of the second terminal device 402. For example, the assistance data may be SLPP Provide Assistance Data. The assistance data may include the first SL-PRS configuration, where the first SL-PRS configuration is associated with the SLPP session of the second terminal device 402.

In one implementation, the feedback information 422 may indicate that the first SL-PRS configuration is accepted. In some example embodiments, the first terminal device 401 may determine to accept the received first SL-PRS configuration. For example, if there is no other SL-PRS configuration is performed at the first terminal device 401, the first terminal device 401 may determine to accept the received first SL-PRS configuration. For example, the first terminal device 401 complies assistance data from different target terminal devices/server terminal devices, such as the terminal device 320 and the terminal device 330 as shown in FIG. 3, even if an SL-PRS configuration of the terminal device 330 is performed at the first terminal device 401, and the first terminal device 401 may determine to accept the received first SL-PRS configuration. For example, if the first SL-PRS configuration conflicts with one or more SL-PRS configurations (ongoing SL-PRS configurations) being performed at the first terminal 401, and the service associated with the first SL-PRS configuration has a higher priority than one or more services associated with one or more SL-PRS configurations being performed at the first terminal 401, then the first terminal device 401 may determine to accept the received first SL-PRS configuration. For example, the first terminal device 401 can be served as an anchor terminal device for only one SLPP session at a same time, and the service associated with the first SL-PRS configuration has a higher priority than a service associated with one or more SL-PRS configurations (ongoing SL-PRS configurations) being performed at the first terminal device 401, then the first terminal device 401 may determine to accept the received first SL-PRS configuration.

As an example, the priority is higher may refer to a service requirement is higher. For example, the first SL-PRS configuration is associated with a service (or a positioning service) of the second terminal device 402, and an ongoing SL-PRS configuration is associated with another service of another second terminal device. If the service requirement (such as accuracy or latency requirement) associated with the first SL-PRS configuration is higher than the service requirement associated with the ongoing SL-PRS configuration, in other words, the service associated with the first SL-PRS configuration has more stringent requirement, then the first terminal device 401 may determine that the priority of the service associated with the first SL-PRS configuration is higher.

In some examples, if the first terminal device 401 determines to accept the received first SL-PRS configuration, it may transmit the feedback information 422 which includes an accept indication explicitly. In some examples, if the first terminal device 401 determines to accept the received first SL-PRS configuration, the feedback information includes a measurement result associated with the received first SL-PRS configuration, and the measurement result may implicitly indicate that the first SL-PRS configuration is accepted.

In some examples, if the first SL-PRS configuration conflicts with one or more SL-PRS configurations (ongoing SL-PRS configurations) being performed at the first terminal 401, and the service associated with the first SL-PRS configuration has a higher priority than one or more services associated with one or more SL-PRS configurations being performed at the first terminal 401, then the first terminal device 401 may determine to accept the received first SL-PRS configuration, and the first terminal device 401 may further release the one or more SL-PRS configurations (ongoing SL-PRS configurations) being performed at the first terminal device 401. In some other examples, if the first terminal device 401 can be served as an anchor terminal device for only one SLPP session at a same time, and the service associated with the first SL-PRS configuration has a higher priority than service (s) associated with one or more SL-PRS configurations being performed at the first terminal device 401, and the first terminal device 401 determines to accept the received first SL-PRS configuration, the first terminal device 401 may further release the one or more SL-PRS configurations (ongoing SL-PRS configurations) being performed at the first terminal device 401. In some examples, the first terminal device 401 may further transmit a termination indication (or an abort indication) to a T-UE or S-UE of the ongoing SL-PRS configuration.

In another implementation, the feedback information 422 may indicate that the first SL-PRS configuration is not accepted, for example, the first SL-PRS configuration is rejected. In some example embodiments, the first terminal device 401 may determine to not accept (or reject) the received first SL-PRS configuration. For example, if the first terminal device 401 can be served as an anchor terminal device for only one SLPP session at a same time, and the first terminal device 401 is performing one or more SL-PRS configurations (different from the first SL-PRS configuration) , then the first terminal device 401 may determine to reject the received first SL-PRS configuration. For example, the first terminal device 401 can be served as an anchor terminal device for only one SLPP session at a same time, and the service associated with the first SL-PRS configuration has a lower priority than service (s) associated with the one or more SL-PRS configurations (ongoing SL-PRS configurations) being performed at the first terminal device 401, then the first terminal device 401 may determine to reject the received first SL-PRS configuration.

For example, the first SL-PRS configuration is associated with a service (or a positioning service) of the second terminal device 402, and an ongoing SL-PRS configuration is associated with another service of another second terminal device. If the service requirement (such as accuracy or latency requirement) associated with the first SL-PRS configuration is lower than the service requirement associated with the ongoing SL-PRS configuration, in other words, the service associated with the first SL-PRS configuration has relax stringent requirement, then the first terminal device 401 may determine that the priority of the service associated with the first SL-PRS configuration is lower.

In some examples, the feedback information 422 may include a reject indication, as such, the rejection may be indicated explicitly.

In some examples, the feedback information 422 may include reason that the first SL-PRS configuration is rejected. For example, the reason may be: there is an SL-PRS configuration confliction at the first terminal device 401. For example, the reason may be indicated by one of: a cause value, a reject code, a reject text, or the like. For example, in case there is no explicit reject indication included in the feedback information 422, the reason may indicate the rejection implicitly.

In some examples, the feedback information 422 may include the one or more SL-PRS configurations (the ongoing SL-PRS configurations) being performed at the first terminal device 401 and/or a suggested SL-PRS configuration. For example, the first terminal device 401 may determine or generate a desired or preferred new SL-PRS configuration as the suggested SL-PRS configuration, it is to be understood that the suggested SL-PRS configuration is not conflicted with the ongoing SL-PRS configurations. For example, in case there is no explicit reject indication included in the feedback information 422, the ongoing SL-PRS configuration and/or the suggested SL-PRS configuration may indicate the rejection implicitly.

In some examples, in response to receiving the feedback information 422 indicates not to accept (i.e., reject) the first SL-PRS configuration, the second terminal device 402 may determine or generate an updated SL-PRS configuration, and may further transmit updated assistance data including the updated SL-PRS configuration to the first terminal device 401. For example, the updated SL-PRS configuration may be determined or generated based on the ongoing SL-PRS configurations or the suggested SL-PRS configuration in the feedback information 422. In some other examples, in response to receiving the feedback information 422 indicates not to accept (i.e., reject) the first SL-PRS configuration, the second terminal device 402 may select other terminal device (s) to be the anchor terminal device (s) .

In some other example embodiments, the first terminal device 401 may further transmit second information to the second terminal device 402. In some examples, the second information may be transmitted before the reception of the first information. In some examples, the second information may be positioning capability information, such as an SLPP Provide Capabilities message. In some examples, the second information may be SLPP Request Assistance Data message.

In some examples, the second information may include the one or more SL-PRS configurations (the ongoing SL-PRS configurations) being performed at the first terminal device 401 and/or a suggested SL-PRS configuration. For example, the first terminal device 401 is performing an SL-PRS configuration, and may determine or generate a desired or preferred new SL-PRS configuration as the suggested SL-PRS configuration.

In some examples, the second information may include one or more service requirements (such as accuracy or latency requirement) associated with the one or more SL-PRS configurations (the ongoing SL-PRS configurations) being performed at the first terminal device 401 to the second terminal device 402.

In some examples, the second terminal device 402 may receive the second information, for example, the second terminal device 402 may obtain one or more of: the one or more SL-PRS configurations being performed at the first terminal device 401, the suggested SL-PRS configuration, or the one or more service requirements associated with the one or more SL-PRS configurations (the ongoing SL-PRS configurations) being performed at the first terminal device 401, from the second information. Accordingly, the second terminal device 402 may determine or generate the first SL-PRS configuration based on the second information. For example, the first information 412 may be generated based on the second information from the first terminal device 401, as such, a possibility that the first terminal device 401 accepts the first SL-PRS configuration may be increased. In some other examples, the second terminal device 402 may select other terminal device (s) as the anchor UE (s) .

As a specific example, with reference to FIG. 2, it is assumed the SLPP session 220 is ongoing, that it, A-UE 2 and A-UE 3 are anchor UEs for SLPP session 220 of T-UE 2/S-UE 2, if the assistance data is provided from T-UE 1/S-UE 1 to A-UE 2 and A-UE 3, and the assistance data includes a first SL-PRS configuration associated with SLPP session 210, then A-UE 2 and/or A-UE 3 may transmit feedback information to T-UE 1/S-UE 1, to indicate that the fist SL-PRS configuration is rejected.

According to the embodiments described above, feedback information may be transmitted from the first terminal device to the second terminal device, as such, the second terminal device may be aware of whether a first SL-PRS configuration is accepted at the first terminal device.

Back to refer to FIG. 4, in some example embodiments, the first information 412 may indicate resource information associated with the first SL-PRS configuration. The resource information may be used by the first terminal device 401 to perform a measurement and/or reporting.

In some examples, the first information 412 may include location request information. For example, the second terminal device 402 may transmit the location request information to the first terminal device 401. In some examples, the location request information may be used to indicate the first terminal device 401 to perform PL-PRS measurement and/or reporting. In some examples, the location request information may include one or more of: quality of service (QoS) parameters, scheduled location time, and reporting configuration.

In some examples, there may be first resource information dedicated or specific to the second terminal device 402. For example, the first resource information may be UE-specific resource information. For example, the first resource information may be configured or pre-configured for the second terminal device 402. Alternatively, a network device (such as the network device 350) may configure or allocate the first resource information for the second terminal device 402. For example, the first resource information dedicated or specific to the second terminal device 402 may include one or more of: a resource set, a resource block, or a resource pool.

In some other examples, there may be second resource information dedicated or specific to an SLPP session involving the first terminal device 401 and the second terminal device 402. For example, the second resource information may be SLPP session-specific resource information. For example, the second resource information may be configured or pre-configured within the first resource information. For example, the second resource information dedicated or specific to the SLPP session involving the first terminal device 401 and the second terminal device 402 may include one or more of: a resource set, a resource block, or a resource pool.

As one example, the second resource information may be part of the first resource information dedicated or specific to the second terminal device 402. For example, the second terminal device 402 may determine the second resource information from the first resource information.

In some cases, the SLPP session may involve multiple A-UEs, and the second terminal device 402 may allocate the first resource information or the second resource information to the multiple A-UEs.

In some examples, there may be multiple SLPP sessions at the second terminal device 402, the second terminal device 402 may allocate different resource information for different SLPP sessions. As a specific example, with reference to FIG. 2, T-UE 1/S-UE 1 may allocate second resource information 1 for SLPP session 210, and allocate second resource information 3 for SLPP session 230.

In some examples, the second terminal device 402 may allocate different resource information associated with different SLPP sessions to the first terminal device 401. In some examples, if different resource information associated with different SLPP sessions have been received at the first terminal device 401, the first terminal device 401 may select the second resource information associated with the SLPP session.

For example, the second terminal device 402 may select a first part of the first (or the second) resource information for the first terminal device 401, and the first information may further indicate or include the first part of the first (or the second) resource information.

The first terminal device 401 receives the location request information from the second terminal device 402. The first terminal device 401 may performs a measurement based on the location request information.

In some examples, the first terminal device 401 may determine feedback information 422 of the first information 401 (such as the location request information) , and transmit the feedback information 422 to the second terminal device 402.

In some example embodiments, the feedback information 422 may include a report. In some examples, the first terminal device 401 may transmit the report on the first part of the first (or the second) resource information. In some examples, the report may include a measurement result, in other words, the feedback information 422 may include a measurement result. In some other examples, the report may be a failure report, for example, the failure report indicates a failure of a measurement or a failure of reporting, in other words, the feedback information 422 may indicate a failure of a measurement or a failure of reporting.

In some examples, if the first terminal device 401 detects a resource confliction at the first terminal device 401, the first terminal device 401 may transmit the feedback information 422 to the second terminal device 402, where the feedback information 422 indicates that there is a resource confliction is detected by the first terminal device 401.

For example, if the first resource information or the second resource information (as described above) is shared among multiple T-UEs/S-UEs, the first terminal device 401 may determine that there is a resource confliction. For example, if there is no available resource information is detected for reporting, the first terminal device 401 may determine that there is a resource confliction. In some examples, the resource confliction may mean that, scheduled resource information (for example, includes time resource) for different SLPP sessions are overlapped, or no available resource information is detected for reporting.

In some examples, the failure report may include a reason of the failure. For example, the failure report may include a cause value, a failure code, a failure text, or the like, the present disclosure does not limit this aspect.

In some examples, the feedback information 422 (for example includes a failure report) may be transmitted to the second terminal device 402, where the second terminal device 402 is one of the multiple T-UEs/S-UEs sharing the first resource information or the second resource information, where the second terminal device 402 has a service with a lowest priority. For example, the service of the second terminal device 402 has less service requirements than other T-UEs/S-UEs.

As a specific example, with reference to FIG. 2, it is assumed the first resource information is shared by T-UE 1/S-UE 1 and T-UE 2/S-UE 2, T-UE 1/S-UE 1 tends to initiate SLPP session 210, and T-UE 2/S-UE 2 tends to initiate SLPP session 220. If a service of SLPP session 210 is more stringent, the failure report may be transmitted from A-UE 2 or A-UE 3 to T-UE 2/S-UE 2. If a service of SLPP session 220 is more stringent, the failure report may be transmitted from A-UE 2 or A-UE 3 to T-UE 1/S-UE 1.

According to some embodiments described above, resource information dedicated or specific to a terminal device (T-UE or S-UE) or an SLPP session may be used. As such, a resource confliction may be avoided in most cases, and the communication efficiency may be improved.

It is to be understood that the embodiments with reference to FIG. 4 are only for the purpose of illustration without any limitation of the present disclosure. In some examples, although some embodiments are described with the first information as assistance data or location request information respectively, in some other cases, the first information may be other information during a sidelink positioning procedure. For example, the first information may be related to one of: a location request, a measurement request, a positioning capability request, or an SLPP assistant data message. In some examples, although some embodiments are described with the first information comprising the first SL-PRS configuration or resource information, in some other cases, the first SL-PRS configuration and resource information may be transmitted separately, i.e., carried in different information and transmitted independently.

FIG. 5 illustrates another example of a process flow 500 in accordance with some example embodiments of the present disclosure. The process flow 500 involves a first terminal device 501 and a second terminal device 502. For the purpose of discussion, the first terminal device 501 may be referred to as an anchor UE, such as A-UE 1, A-UE 2, or A-UE 3 as shown in FIG. 2, such as the terminal device 310-1, or the terminal device 310-2 as shown in FIG. 3. For the purpose of discussion, the second terminal device 502 may be referred to as a target UE or a server UE, such as T-UE 1, S-UE 1, T-UE 2, or S-UE 2 as shown in FIG. 2, such as the terminal device 320-1, the terminal device 320-2, or the terminal device 330 as shown in FIG. 3. It would be appreciated that the process flow 500 may be applied to the network environment 300 of FIG. 3 or other communication scenarios.

The second terminal device 502 may initiate one or more positioning services. In some examples, the anchors UEs involved in different positioning services may be overlapped. For ease of description, it is assumed that the first terminal device 501 is served for multiple positioning services of the second terminal device 502. With reference to FIG. 2, the second terminal device 502 may be T-UE 1/S-UE1, the first terminal device 501 may be A-UE 2 or A-UE 3. For ease of description, it is assumed that the second terminal device 502 initiates multiple positioning services simultaneously or at different time.

In the process flow 500, the second terminal device 502 determines 510 one or more SLPP sessions for multiple positioning services. The second terminal device 502 transmits 520 first information 522 associated with at least one of the multiple positioning services to the first terminal device 501, and the first terminal device 501 receives 524 the first information 522.

In some example embodiments, the first information 522 may be related to any one of: a location request, a measurement request, a positioning capability request, or an SLPP assistant data message. In some example embodiments, the first information 522 may be, or be included in, or include, an SLPP message.

In one implementation, an SLPP session is used to support a single positioning service. The second terminal device 502 may determine (or establish) multiple SLPP sessions for the multiple positioning services respectively.

In some example embodiments, each SLPP message between two terminal devices may include a session identifier (ID) . For example, the first information 522 from the second terminal device 502 (T-UE or S-UE) to the first terminal device 501 (A-UE) may include the session ID, where the first information 522 may be assistance data, location information, etc. For example, with reference to FIG. 3, an SLPP message from a second terminal device 320-1 to a second terminal device 320-2 or from a second terminal device 320-2 to a second terminal device 320-1 (T-UE to S-UE, or S-UE to T-UE) may include the session ID.

In some examples, a session ID is associated with the positioning service which the SLPP session (has the session ID) supported. For example, for a positioning service 1, an SLPP session 1 is established with a session ID 1, then the session ID 1 may correspond to the positioning service 1.

In some example embodiments, each SLPP session may include one or more SLPP transactions, where each of the one or more SLPP transactions is used for performing a sidelink positioning operation. For example, the first information 522 may include a transaction ID. In some examples, the sidelink positioning operation may include one or more of: capability exchange, assistance data transfer, or location information transfer.

In some example embodiments, there may be different SLPP session-specific resources configured or pre-configured at the second terminal device 502. In some examples, each SLPP session may be performed with associated SLPP session-specific resources. For example, the SLPP session-specific resources may include one or more of: a resource set, a resource block, or a resource pool.

In some examples, the second terminal device 502 may allocate (or distribute) the SLPP session-specific resources to multiple anchor UEs (including the first terminal device 501) involved in the SLPP session. Detailed description may be referred to embodiments with reference to FIG. 4 above.

In another implementation, an SLPP session is used to support multiple positioning services. In some example embodiments, the second terminal device 502 may determine whether different positioning services can be supported by a single SLPP session.

In some example embodiments, the second terminal device 502 may determine a difference of requirements of different positioning services both involving the first terminal device 501 as an anchor UE. The second terminal device 502 may further determine whether the different positioning services may be supported by a single SLPP session. For example, a threshold may be used to compare with the difference of requirements of different positioning services.

As an example, assume that a first positioning service and a second positioning service both involve the first terminal device 501 as an anchor UE. In some examples, the second terminal device 502 may determine a difference of a first service requirement of the first positioning service and a second service requirement of the second positioning service. In some examples, the second terminal device 502 may determine whether the difference is lower than or not greater than a threshold, for example, the difference may be compared with the threshold. In some examples, if the difference is lower than or not greater than a threshold, the second terminal device 502 may determine that the first positioning service and the second positioning service may be supported by a single SLPP session, for example, the second terminal device 502 may determine (or establish) an SLPP session associated with both the first positioning service and the second positioning service. Otherwise, if the difference is not lower than or greater than a threshold, the second terminal device 502 may determine that the first positioning service and the second positioning service cannot be supported by a single SLPP session, for example, the second terminal device 502 may determine (or establish) different SLPP sessions for the first positioning service and the second positioning service respectively.

In some examples, the threshold may be configured or pre-configured for the second terminal device 502. In some examples, a network device (such as the network device 350 in FIG. 3) may transmit the threshold to the second terminal device 502 (such as the terminal device 320-1) , for example, if the SLPP session is controlled by the network device 350.

In some example embodiments, if the second terminal device 502 determines that different positioning services can be supported by a single SLPP session, it is understood that a session ID may be associated with multiple positioning services which the SLPP session (has the session ID) supported. For example, an SLPP session 1 is established with a session ID 1 to support both a positioning service 1 and a positioning service 3, then the session ID 1 may correspond to both the positioning service 1 and the positioning service 3.

In some examples, an SLPP message between two terminal devices for different positioning services may be transmitted by common first information 522, or may be transmitted by separate first information 522. In some examples, the first information 522 may include one or more positioning service IDs.

For example, the first information 522 from the second terminal device 502 (T-UE or S-UE) to the first terminal device 501 (A-UE) may be transmitted associated with multiple positioning services, and the first information 522 may include multiple positioning service IDs of the multiple positioning services, the first information 522 may be assistance data, location information, etc. For example, with reference to FIG. 3, an SLPP message from a second terminal device 320-1 to a second terminal device 320-2 or from a second terminal device 320-2 to a second terminal device 320-1 (T-UE to S-UE, or S-UE to T-UE) may be transmitted associated with multiple positioning services. As one example, the second terminal device 502 may transmit a single SLPP location information request message, which includes the location information for multiple positioning services, if a same positioning method can be used for the multiple positioning services.

For example, the first information 522 from the second terminal device 502 (T-UE or S-UE) to the first terminal device 501 (A-UE) may be transmitted associated with one of the multiple positioning services, and the first information 522 may include a positioning service ID of the one of the multiple positioning services. For example, the second terminal device 502 may transmit first information 1 including a positioning service ID 1 associated with a positioning service 1, and transmit first information 3 including a positioning service ID 3 associated with a positioning service 3.

In some examples, the SLPP session may include one or more SLPP transactions, where each of the one or more SLPP transactions is used for performing a sidelink positioning operation. For example, the first information 522 may include a transaction ID. In some examples, the sidelink positioning operation may include one or more of: capability exchange, assistance data transfer, or location information transfer. In some examples, the sidelink positioning operation may be targeted for one positioning service or for multiple positioning services.

In some example embodiments, different positioning services may not be initiated at a same time or within a short time duration. In some examples, a positioning service (acurrent positioning service) has been initiated, for example, an SLPP session (a current SLPP session) with a session ID (such as session ID 1) has been established. The second terminal device 502 may determine whether the current SLPP session can support a new positioning service. If the current SLPP session can support the new positioning service, then the second terminal device 502 can use the session ID (session ID 1) for the new positioning service, in other words, the current SLPP session with session ID 1 is used to support both the current positioning service and the new positioning service, and the session ID (session ID 1) corresponds to both the current positioning service and the new positioning service.

In some examples, the second terminal device 502 may determine whether the involved anchor UEs of the current SLPP session are overlapped with those for the new positioning service, for example, both the current positioning service and the new positioning service involve the first terminal device 501. In some examples, the second terminal device 502 may determine a difference of requirements of the current and the new positioning services both involving the first terminal device 501 as an anchor UE. For example, a threshold may be used to compare with the difference of requirements of different positioning services. If the difference is lower than or not greater than a threshold, the second terminal device 502 may determine that the current SLPP session can support the new positioning service. Otherwise, if the difference is not lower than or greater than a threshold, the second terminal device 502 may determine that the current SLPP session cannot support the new positioning service, and the second terminal device 502 may establish a new SLPP session for the new positioning service. In some examples, the second terminal device 502 may determine whether one or more SL-PRS configurations for the current session can satisfy the service requirements of the new positioning service. If the one or more SL-PRS configurations for the current session can satisfy the service requirements of the new positioning service, the second terminal device 502 may determine that the current SLPP session can support the new positioning service. Otherwise, if the one or more SL-PRS configurations for the current session cannot satisfy the service requirements of the new positioning service, the second terminal device 502 may determine that the current SLPP session cannot support the new positioning service, and the second terminal device 502 may establish a new SLPP session for the new positioning service.

In case the second terminal device 502 determines that the current SLPP session can support the new positioning service, in some examples, the second terminal device 502 may use the current positioning method and corresponding assistance data for the new positioning service, or the second terminal device 502 may use an updated positioning method and corresponding updated assistance data for the new positioning service. For example, if assistance data for the current positioning service can also be used for the new positioning service, there is no need for the second terminal device 502 to transmit the same assistance data again, or there is no need for the first terminal device 501 d to request new assistance data. On the other hand, if the current SLPP session cannot support the new positioning service, the second terminal device 502 may determine or establish a new SLPP session with a new session ID for the new positioning service.

FIG. 6 illustrates an example of a process flow 600 that an SLPP session supports only one positioning service in accordance with some example embodiments of the present disclosure. The process flow 600 is described with reference to FIG. 2, and the process flow 600 is related to T-UE 1 and A-UE 2/3.

T-UE 1 initiates a positioning service 1 and a positioning service 3 both involving A-UE 2 and A-UE 3. In case that an SLPP session is used to supported only one single positioning service, T-UE 1 establishes an SLPP session 1 with a session ID 1 for the positioning service 1 and an SLPP session 3 with a session ID 3 for the positioning service 3. T-UE 1 may transmit first information which includes corresponding session ID.

As shown in FIG. 6, T-UE 1 transmits assistance data with session ID 1 to A-UE 2/3 at 610, T-UE 1 transmits assistance data with session ID 3 to A-UE 2/3 at 620. T-UE 1 transmits location information with session ID 1 to A-UE 2/3 at 630, T-UE 1 transmits location information with session ID 3 to A-UE 2/3 at 640.

FIG. 7 illustrates an example of a process flow 700 that an SLPP session supports multiple positioning services in accordance with some example embodiments of the present disclosure. The process flow 700 is described with reference to FIG. 2, and the process flow 700 is related to T-UE 1 and A-UE 2/3.

T-UE 1 initiates a positioning service 1 and a positioning service 3 both involving A-UE 2 and A-UE 3. It is assumed that the positioning service 1 has a positioning service ID 1, and the positioning service 3 has a positioning service ID 3. In case that an SLPP session is used to supported multiple positioning services, T-UE 1 determines a difference of a service requirement of the positioning service 1 and a service requirement of the positioning service 3. In some examples, if the difference is lower than a threshold, for example, the positioning service 1 and the positioning service 3 have similar accuracy and latency requirements, T-UE 1 may establish an SLPP session to support both the positioning service 1 and the positioning service 3.

T-UE 1 may transmit common first information for both the positioning service 1 and the positioning service 3. As shown in FIG. 7, at block 710, T-UE 1 transmits assistance data to A-UE 2/3 at 712, T-UE 1 transmits location information to A-UE 2/3 at 714, where each of the assistance data and the location information may include positioning service IDs 1 and 3.

T-UE 1 may transmit first information for the positioning service 1 and the positioning service 3 separately. As shown in FIG. 7, at block 720, T-UE 1 transmits assistance data with positioning service ID 1 to A-UE 2/3 at 722, T-UE 1 transmits assistance data with positioning service ID 3 to A-UE 2/3 at 724. T-UE 1 transmits location information with positioning service ID 1 to A-UE 2/3 at 726, T-UE 1 transmits location information with positioning service ID 3 to A-UE 2/3 at 728.

According to embodiments with reference to FIGS. 5-7, a T-UE/S-UE may determine one or more SLPP sessions for multiple positioning services, in some cases, it is possible that a single SLPP session is used to support multiple positioning services, as such, the communication efficiency may be improved.

It is to be understood that some embodiments with reference to FIG. 4 and some embodiments with reference to FIG. 5 may be combined to form some other embodiments, for example, feedback information may be transmitted in process flow 500 in some cases. The present disclosure will not list in detail herein.

FIG. 8 illustrates an example of a process flow 800 of session abortion in accordance with some example embodiments of the present disclosure. The process flow 800 involves a first terminal device 801 and a second terminal device 802. For the purpose of discussion, the first terminal device 801 may be referred to as an anchor UE, such as A-UE 1, A-UE 2, or A-UE 3 as shown in FIG. 2, such as the terminal device 310-1, or the terminal device 310-2 as shown in FIG. 3. For the purpose of discussion, the second terminal device 802 may be referred to as a target UE or a server UE, such as T-UE 1, S-UE 1, T-UE 2, or S-UE 2 as shown in FIG. 2, such as the terminal device 320-1, the terminal device 320-2, or the terminal device 330 as shown in FIG. 3. It would be appreciated that the process flow 800 may be applied to the network environment 300 of FIG. 3 or other communication scenarios.

In the process flow 800, the first terminal device 801 and the second terminal device 802 are performing 810 an SLPP session associated with a sidelink positioning. Specifically, the second terminal device 802 (as a T-UE or S-UE) is performing the SLPP session with multiple A-UEs which include the first terminal device 801, for example, the first terminal device 801 may be any one of the multiple A-UEs. In some examples, the SLPP session may be associated with one positioning service or multiple positioning services of the second terminal device 802.

Alternatively, the first terminal device 801 may determine 815 to abort the SLPP session. For example, the first terminal device 801 is moving away from the second terminal device 802, the first terminal device 801 has a low battery and does not want to be an anchor UE anymore, the first terminal device 801 would like to perform another SLPP session, etc. The first terminal device 801 may transmit 820 an abortion indication 822 to the second terminal device 802, where the abortion indication 822 indicates that the SLPP session with the second terminal device 802 is aborted at the first terminal device 801, and the abortion indication 822 may include a session ID of the SLPP session.

In some examples, there may be multiple SLPP sessions performed at the first terminal device 801, that is, the first terminal device 801 is involved in multiple SLPP sessions as an anchor UE, in this case, the first terminal device 801 may determine to abort one or more of the multiple SLPP sessions. For example, the first terminal device 801 may determine to abort only the SLPP session with the second terminal device 802, e.g., the SLPP session with the second terminal device 802 is associated with a positioning service has a lower service requirement. For example, the first terminal device 801 may determine to abort all of the multiple SLPP sessions.

In some examples, the first terminal device 801 may disconnect the link with the second terminal device 802. It is to be understood that a T-UE or an S-UE can decide whether an SLPP session may be aborted. Accordingly, the second terminal device 802 may receive 824 the abortion indication from the first terminal device 801.

In the process flow 800, the second terminal device 802 determines 825 to abort the SLPP session. In some examples, if an abortion condition is met, the second terminal device 802 may determine to abort the SLPP session. The abortion condition may be one of: number of failed links among all links between the second terminal device and the multiple first terminal devices exceeds a first threshold, a portion of failed links among all links between the second terminal device and the multiple first terminal devices exceeds a second threshold, a link between the second terminal device and a third terminal device is failed, wherein the second terminal device is one of a target terminal device or a server terminal device, and the third terminal device is another one of the target terminal device or the server terminal device, a service requirement of the SLPP session cannot be satisfied, or an indication is received from a first terminal device.

In some example embodiments, the abortion condition may be associated with one or more radio link failures of the SLPP unicast links (or connections) . In some examples, the links in the SLPP session include: a link between a T-UE and an S-UE, multiple links between a T-UE and multiple A-UEs, multiple links between an S-UE and multiple A-UEs.

For example, if any one of links in the SLPP session is failed, or if any one of the links between a T-UE and multiple A-UEs is failed, or if any one of the links between an S-UE and multiple A-UEs is failed, or a link between a T-UE and an S-UE is failed, the second terminal device 802 may determine to abort the SLPP session.

For example, if a number of failed links among links in the SLPP session exceeds a first threshold 1, or if a number of failed links among links between a T-UE and multiple A-UEs exceeds a first threshold 2, or if a number of failed links among links between an S-UE and multiple A-UEs exceeds a first threshold 3, the second terminal device 802 may determine to abort the SLPP session. The first threshold 1, 2, 3 may be the same, or may be different.

For example, if a portion of failed links among links in the SLPP session exceeds a second threshold 1, or if a portion of failed links among links between a T-UE and multiple A-UEs exceeds a second threshold 2, or if a portion of failed links among links between an S-UE and multiple A-UEs exceeds a second threshold 3, the second terminal device 802 may determine to abort the SLPP session. The second threshold 1, 2, 3 may be the same, or may be different.

It is to be understood that the threshold (s) for determining whether to abort the SLPP session, such as the first threshold and/or the second threshold, may be predefined at the second terminal device 802, or may be preconfigured by a network device.

In some example embodiments, the abortion condition may be associated with a UE capability or a service requirement. For example, if a UE capability or a service requirement cannot be satisfied, the second terminal device 802 may determine to abort the SLPP session associated with the positioning service which cannot be satisfied.

In some examples, there may be multiple SLPP sessions performed at the second terminal device 802, in this case, the second terminal device 802 may determine to abort one or more of the multiple SLPP sessions. For example, the second terminal device 802 may determine to abort only the SLPP session with the first terminal device 801, e.g., the SLPP session with the first terminal device 801 is associated with a positioning service has a lower service priority among the multiple SLPP sessions. For example, the second terminal device 802 may determine to abort all of the multiple SLPP sessions.

In some examples, the SLPP session performed with the first terminal device 801 may be associated with multiple positioning services. If a service requirement of one of the multiple positioning services cannot be satisfied, the second terminal device 802 may determine to abort the SLPP session. If the service requirements of all of the multiple positioning services cannot be satisfied, the second terminal device 802 may determine to abort the SLPP session.

In some other examples, if an abortion indication is received from at least one anchor UE, the second terminal device 802 may determine whether to abort the SLPP session with the at least one anchor UE. For example, if an abortion indication 822 is received from the first terminal device 801, the second terminal device 802 may determine to abort the SLPP session. For another example, even an abortion indication 822 is received from the first terminal device 801, the second terminal device 802 may determine not to abort the SLPP session, for example, the SLPP session is further performed with other A-UEs, for example, the second terminal device 802 may select anther A-UE rather than the first terminal device 801.

Continue referring to FIG. 8, the second terminal device 802 transmits 830 an abortion indication 832 to the first terminal device 801. Accordingly, the first terminal device 801 receives 834 the abortion indication 832.

In some examples, if the second terminal device 802 determines to abort the SLPP session, the second terminal device 802 may transmit the abortion indication 832 to one or more (such as all of) A-UEs involved in the SLPP session. In some examples, the abortion indication 832 may indicate that the SLPP session is aborted, in some examples, the abortion indication 832 may include a session ID of the SLPP session.

It is to be understood that the term “abort” in the present disclosure may be replaced by “terminate” in some examples, for examples, the first terminal device 801 or the second terminal device 802 may determine whether to terminate or abort the SLPP session. For example, a termination condition or an abortion condition may be considered. For example, a termination indication may be transmitted.

According to embodiments with reference to FIG. 8, an SLPP session may be terminated or aborted in some cases. As such, a procedure of how to terminate or abort an SLPP session is defined, considering a terminal device may involve multiple SLPP sessions, the termination or abortion of one SLPP session may be beneficial for other SLPP session (s) , for example, the resources for the terminated or aborted SLPP session may be used for other SLPP session (s) , therefore the resource utilization rate may be improved.

It is to be understood that some embodiments with reference to FIG. 8 may be combined with some embodiments with reference to FIG. 4 or FIG. 5, for example, the process flow 800 may be performed after process flow 400 or 500.

EXAMPLE METHOD

FIG. 9 illustrates a flowchart of an example method 900 for communication in accordance with some embodiments of the present disclosure. In some embodiments, the method 900 can be implemented at an anchor terminal device (a first terminal device) in a communication network. In some examples, the first terminal device may be A-UE 1, A-UE 2, or A-UE 3 as shown in FIG. 2, or the terminal device 310-1, or the terminal device 310-2 as shown in FIG. 3. In some other embodiments, the method 900 may be implemented at devices not shown in FIGS. 2-3. Further, it is to be understood that the method 900 may include additional blocks not shown and/or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

At block 910, the first terminal device receives, from a second terminal device, first information associated with a sidelink positioning, where the first information comprises a first SL-PRS configuration. At block 920, the first terminal device determines feedback information of the first information, where the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device. At block 930, the first terminal device transmits, to the second terminal device, the feedback information.

In some example embodiments, the feedback information indicates that the first SL-PRS configuration is not accepted, and the feedback information comprises at least one of: a reason that the first SL-PRS configuration is rejected, one or more SL-PRS configurations being performed at the first terminal device, or a suggested SL-PRS configuration.

In some other example embodiments, the feedback information indicates that the first SL-PRS configuration is accepted in accordance with a determination that: there is no SL-PRS configuration being performed at the first terminal device, or a service associated with the first SL-PRS configuration has a higher priority than one or more services associated with one or more SL-PRS configurations being performed at the first terminal device. In some examples, the first terminal device releases the one or more SL-PRS configurations being performed at the first terminal device.

In some other example embodiments, the first terminal device transmits, to the second terminal device, second information which comprises at least one of: one or more SL-PRS configurations being performed at the first terminal device, a suggested SL-PRS configuration, or one or more service requirements of one or more services associated with the one or more SL-PRS configurations.

In some other example embodiments, the first SL-PRS configuration is associated with first resource information dedicated to the second terminal device.

In some other example embodiments, the first SL-PRS configuration is associated with second resource information for an SLPP session involving the first terminal device and the second terminal device, where the second resource information is part of the first resource information.

In some other example embodiments, the feedback information indicates that the first SL-PRS configuration is not accepted in accordance with a determination that a resource confliction is detected by the first terminal device, in the case that the first resource information or the second resource information is shared among multiple second terminal devices.

In some other example embodiments, the first terminal device transmits the feedback information indicating that the first SL-PRS configuration is not accepted, to the second terminal device, associated with which the SLPP session has less service requirements than other second terminal devices.

In some other example embodiments, the first information is related to a location request, a measurement request, a positioning capability request, or an SLPP assistant data message.

In some other example embodiments, the first information further comprises a session identifier (ID) and a transaction ID.

In some other example embodiments, the first terminal device performs an SLPP session associated with the sidelink positioning with the second terminal device; determines to abort the SLPP session; and transmits, to the second terminal device, an abortion indication indicating that the SLPP session is aborted at the first terminal device, wherein the abortion indication comprises a session ID of the SLPP session.

FIG. 10 illustrates a flowchart of an example method 1000 for communication in accordance with some embodiments of the present disclosure. In some embodiments, the method 1000 can be implemented at a target terminal device or a server terminal device (asecond terminal device) in a communication network. In some examples, the second terminal device may be referred to as a target UE or a server UE, such as T-UE 1, S-UE 1, T-UE 2, or S-UE 2 as shown in FIG. 2, such as the terminal device 320-1, the terminal device 320-2, or the terminal device 330 as shown in FIG. 3. In some other embodiments, the method 1000 may be implemented at devices not shown in FIGS. 2-3. Further, it is to be understood that the method 1000 may include additional blocks not shown and/or may omit some blocks as shown, and the scope of the present disclosure is not limited in this regard.

At block 1010, the second terminal device transmits, to a first terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first SL-PRS configuration. At block 1020, the second terminal device receives, from the first terminal device, feedback information of the first information, where the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device.

In some example embodiments, the feedback information indicates that the first SL-PRS configuration is not accepted, and the feedback information comprises at least one of: a reason that the first SL-PRS configuration is rejected, one or more SL-PRS configurations being performed at the first terminal device, or a suggested SL-PRS configuration. In some other example embodiments, the feedback information indicates that the first SL-PRS configuration is accepted.

In some example embodiments, the second terminal device further receives, from the first terminal device, second information which comprises at least one of: one or more SL-PRS configurations being performed at the first terminal device, a suggested SL-PRS configuration, or one or more service requirements of one or more services associated with the one or more SL-PRS configurations.

In some example embodiments, the first SL-PRS configuration is associated with first resource information dedicated to the second terminal device.

In some example embodiments, the first SL-PRS configuration is associated with second resource information for an SLPP session involving the first terminal device and the second terminal device, where the second resource information is part of the first resource information.

In some example embodiments, the feedback information indicates that the first SL-PRS configuration is not accepted, and the feedback information further indicates that a resource confliction is detected by the first terminal device.

In some example embodiments, the first information is related to a location request, a measurement request, a positioning capability request, or an SLPP assistant data message.

In some example embodiments, the first information further comprises a session identifier (ID) and a transaction ID. In some example embodiments, the session ID corresponds to one or more positioning services.

In some example embodiments, if different first information associated with different positioning services involving the same first terminal device, the second terminal device determines a difference of requirements of the one or more positioning services; and if the difference is lower than or not greater than a threshold, the second terminal device uses the session ID corresponding to the one or more positioning services.

In some example embodiments, the first information further comprises one or more positioning service IDs.

In some example embodiments, the second terminal device performs an SLPP session associated with the sidelink positioning with multiple first terminal devices; the second terminal device determines to abort the SLPP session based on one of: a number of failed links among all links between the second terminal device and the multiple first terminal devices exceeds a first threshold, a portion of failed links among all links between the second terminal device and the multiple first terminal devices exceeds a second threshold, a link between the second terminal device and a third terminal device is failed, wherein the second terminal device is one of a target terminal device or a server terminal device, and the third terminal device is another one of the target terminal device or the server terminal device, or a service requirement of the SLPP session cannot be satisfied.

In some example embodiments, the second terminal device transmits, to the first terminal devices, an abortion indication indicating that the SLPP session is aborted.

In some example embodiments, the SLPP session is an SLPP session with a lowest service priority among multiple SLPP sessions of the second terminal device.

In some example embodiments, the second terminal device performs an SLPP session associated with the sidelink positioning with the first terminal device; and receives, from the first terminal device, an abortion indication indicating that the SLPP session is aborted at the first terminal device, wherein the abortion indication comprises a session ID of the SLPP session.

EXAMPLE APPARATUS

FIG. 11 illustrates a simplified block diagram of an apparatus 1100 (also termed as a device 1100) that is suitable for implementing embodiments of the present disclosure. The apparatus 1100 can be considered as a further example implementation of the first terminal device and the second terminal device as described above, such as terminal device (s) 310, terminal device (s) 320, and terminal device 330 as shown in FIG. 3. Accordingly, the apparatus 1100 can be implemented at or as at least a part of the first terminal device and the second terminal device.

As shown, the apparatus 1100 includes a processor 1110, a memory 1120 coupled to the processor 1110, a suitable transmitter (TX) and receiver (RX) 1140 coupled to the processor 1110, and a communication interface coupled to the TX/RX 1140. The memory 1120 stores at least a part of a program 1130. The TX/RX 1140 is for bidirectional communications. The TX/RX 1140 has at least one antenna to facilitate communication, though in practice an Access Node mentioned in this application may have several ones. The communication interface may represent any interface that is necessary for communication with other network elements, such as X2 interface for bidirectional communications between eNBs, S1 interface for communication between a Mobility Management Entity (MME) /Serving Gateway (S-GW) and the eNB, Un interface for communication between the eNB and a relay node (RN) , Uu interface for communication between the eNB and a terminal device, or PC5 interface for communication between two terminal devices.

The program 1130 is assumed to include program instructions that, when executed by the associated processor 1110, enable the apparatus 1100 to operate in accordance with the embodiments of the present disclosure, as discussed herein. The embodiments herein may be implemented by computer software executable by the processor 1110 of the apparatus 1100, or by hardware, or by a combination of software and hardware. The processor 1110 may be configured to implement various embodiments of the present disclosure. Furthermore, a combination of the processor 1110 and memory 1120 may form processing means 1150 adapted to implement various embodiments of the present disclosure.

The memory 1120 may be of any type suitable to the local technical network and may be implemented using any suitable data storage technology, such as a non-transitory computer readable storage medium, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory, as non-limiting examples. While only one memory 1120 is shown in the apparatus 1100, there may be several physically distinct memory modules in the apparatus 1100. The processor 1110 may be of any type suitable to the local technical network, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The apparatus 1100 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

In some embodiments, an apparatus (for example, the first terminal device) capable of performing the method 900 may comprise means for performing the respective steps of the method 900. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the method 900.

In some embodiments, the apparatus comprises: means for receiving, from a second terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first SL-PRS configuration; means for determining feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device; and means for transmitting, to the second terminal device, the feedback information.

IIn some embodiments, an apparatus (for example, the second terminal device) capable of performing the method 1000 may comprise means for performing the respective steps of the method 1000. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the method 1000.

In some embodiments, the apparatus comprises: means for transmitting, to a first terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first SL-PRS configuration; and means for receiving, from the first terminal device, feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representation, it will be appreciated that the blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the process or method as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

The above program code may be embodied on a machine readable medium, which may be any tangible medium that may contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine readable medium may be a machine readable signal medium or a machine readable storage medium. A machine readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the machine readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in language specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A first terminal device comprising:

a processor; and

a transceiver coupled to the processor,

wherein the processor is configured to:

receive, via the transceiver, from a second terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration;

determine feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device; and

transmit, via the transceiver, to the second terminal device, the feedback information.
The first terminal device of claim 1, wherein the feedback information indicates that the first SL-PRS configuration is not accepted, and the feedback information comprises at least one of:

a reason that the first SL-PRS configuration is rejected,

one or more SL-PRS configurations being performed at the first terminal device, or

a suggested SL-PRS configuration.
The first terminal device of claim 1, wherein the feedback information indicates that the first SL-PRS configuration is accepted in accordance with a determination that:

there is no SL-PRS configuration being performed at the first terminal device, or

a service associated with the first SL-PRS configuration has a higher priority than one or more services associated with one or more SL-PRS configurations being performed at the first terminal device.
The first terminal device of claim 1, wherein the processor is further configured to:

transmit, via the transceiver, to the second terminal device, second information which comprises at least one of:

one or more SL-PRS configurations being performed at the first terminal device,

a suggested SL-PRS configuration, or

one or more service requirements of one or more services associated with the one or more SL-PRS configurations.
The first terminal device of claim 1, wherein the first SL-PRS configuration is associated with first resource information dedicated to the second terminal device.
The first terminal device of claim 5, wherein the first SL-PRS configuration is associated with second resource information for an SLPP session involving the first terminal device and the second terminal device, wherein the second resource information is part of the first resource information.
The first terminal device of claim 1, wherein the first information is related to a location request, a measurement request, a positioning capability request, or an SLPP assistant data message.
The first terminal device of claim 1, wherein the processor is further configured to:

perform an SLPP session associated with the sidelink positioning with the second terminal device;

determine to abort the SLPP session; and

transmit, via the transceiver, to the second terminal device, an abortion indication indicating that the SLPP session is aborted at the first terminal device, wherein the abortion indication comprises a session ID of the SLPP session.
A second terminal device comprising:

a processor; and

a transceiver coupled to the processor,

wherein the processor is configured to:

transmit, via the transceiver, to a first terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration; and

receive, via the transceiver, from the first terminal device, feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device.
The second terminal device of claim 9, wherein the first information further comprises a session identifier (ID) and a transaction ID.
The second terminal device of claim 10, wherein the session ID corresponds to one or more positioning services.
The second terminal device of claim 11, wherein the processor is further configured to:

in accordance with a determination that different first information associated with different positioning services involving the same first terminal device, determine a difference of requirements of the one or more positioning services; and

in accordance with a determination that the difference is lower than or not greater than a threshold, use the session ID corresponding to the one or more positioning services.
The second terminal device of claim 9, wherein the processor is further configured to:

perform an SLPP session associated with the sidelink positioning with multiple first terminal devices;

determine to abort the SLPP session based on one of:

a number of failed links among all links between the second terminal device and the multiple first terminal devices exceeds a first threshold,

a portion of failed links among all links between the second terminal device and the multiple first terminal devices exceeds a second threshold,

a link between the second terminal device and a third terminal device is failed, wherein the second terminal device is one of a target terminal device or a server terminal device, and the third terminal device is another one of the target terminal device or the server terminal device, or

a service requirement of the SLPP session cannot be satisfied; and

transmit, via the transceiver, to the first terminal devices, an abortion indication indicating that the SLPP session is aborted.
The second terminal device of claim 9, wherein the processor is further configured to:

perform an SLPP session associated with the sidelink positioning with the first terminal device; and

receive, via the transceiver, from the first terminal device, an abortion indication indicating that the SLPP session is aborted at the first terminal device, wherein the abortion indication comprises a session ID of the SLPP session.
A method performed by a first terminal device, comprising:

receiving, from a second terminal device, first information associated with a sidelink positioning, wherein the first information comprises a first sidelink positioning reference signal (SL-PRS) configuration;

determining feedback information of the first information, wherein the feedback information indicates whether the first SL-PRS configuration is accepted at the first terminal device; and

transmitting, to the second terminal device, the feedback information.