WO2023208382A1

WO2023208382A1 - Handover of positioning reference unit functionality

Info

Publication number: WO2023208382A1
Application number: PCT/EP2022/061604
Authority: WO
Inventors: Oana-Elena Barbu; Prajwal KESHAVAMURTHY; Diomidis Michalopoulos
Original assignee: Nokia Technologies Oy
Priority date: 2022-04-29
Filing date: 2022-04-29
Publication date: 2023-11-02

Abstract

Example embodiments of the present disclosure relate to a terminal device handing over a positioning reference unit (PRU) functionality to one or more other terminal devices. In an example method, a first terminal device transmits a request to a set of terminal devices, which is for a handover of a PRU functionality of the first terminal device. The first terminal device receives a set of respective handover responses from the set of terminal devices. Based on the set of handover responses, the first terminal device determines from the set of terminal devices a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device. The first terminal device transmits to the second terminal device a handover indication of initiating the handover. The example embodiments of the present disclosure can improve positioning performance of terminal devices in a communication network.

Description

HANDOVER OF POSITIONING REFERENCE UNIT FUNCTIONALITY

FIELD

[0001] Example embodiments of the present disclosure generally relate to the field of telecommunication and in particular, to terminal devices, methods, apparatuses and a computer readable storage medium for handing over a positioning reference unit (PRU) functionality from a terminal device to one or more other terminal devices.

BACKGROUND

[0002] In the communication technology, there is a constant evolution ongoing in order to provide efficient and reliable solutions for utilizing wireless communication networks. Each new generation has its own technical challenges for handling different situations and processes that are needed to connect and serve devices connected to wireless networks. To meet the demand for wireless data traffic having increased since deployment of 4th generation (4G) communication systems, efforts have been made to develop an improved 5th generation (5G) or pre-5G communication system. The new communication systems can support various types of service applications for terminal devices.

[0003] The positioning of a terminal device or a mobile device may be useful or essential to a number of applications including emergency calls, navigation, direction finding, asset tracking, Internet service, and V2X applications. In order to improve positioning performance of terminal devices, there are some open problems in sidelink (SL) positioning in 5G New Radio (NR) that will be studied in the near future. Some discussions have been made on the need, use cases and scenarios for SL positioning to be considered for Rel-18 normative work phase. SL positioning will be an enabler of many use cases, most prominently public safety and vehicular applications as well as industrial and commercial applications.

SUMMARY

[0004] In general, example embodiments of the present disclosure provide a solution for handing over a PRU functionality from a terminal device to one or more other terminal devices. [0005] In a first aspect, there is provided a first terminal device. The first terminal device comprises at least one processor and at least one memory storing computer program codes. The at least one memory and the computer program codes are configured to, with the at least one processor, cause the first terminal device to: transmit, to a set of terminal devices, a request for a handover of a PRU functionality of the first terminal device; receive a set of respective handover responses from the set of terminal devices; determine, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and transmit, to the second terminal device, a handover indication of initiating the handover.

[0006] In a second aspect, there is provided a second terminal device. The second terminal device comprises at least one processor and at least one memory storing computer program codes. The at least one memory and the computer program codes are configured to, with the at least one processor, cause the second terminal device to: receive, from a first terminal device, a first request for a handover of a PRU functionality of the first terminal device; and transmit, to the first terminal device, a handover response to the first request.

[0007] In a third aspect, there is provided a method performed by a first terminal device. The method comprises: transmitting, to a set of terminal devices, a request for a handover of a PRU functionality of the first terminal device; receiving a set of respective handover responses from the set of terminal devices; determining, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and transmitting, to the second terminal device, a handover indication of initiating the handover.

[0008] In a fourth aspect, there is provided a method performed by a second terminal device. The method comprises: receiving, from a first terminal device, a first request for a handover of a PRU functionality of the first terminal device; and transmitting, to the first terminal device, a handover response to the first request.

[0009] In a fifth aspect, there is provided an apparatus. The apparatus comprises: means for transmitting, at a first terminal device to a set of terminal devices, a request for a handover of a PRU functionality of the first terminal device; means for receiving a set of respective handover responses from the set of terminal devices; means for determining, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and means for transmitting, to the second terminal device, a handover indication of initiating the handover.

[0010] In a sixth aspect, there is provided an apparatus. The apparatus comprises: means for receiving, at a second terminal device from a first terminal device, a first request for a handover of a PRU functionality of the first terminal device; and means for transmitting, to the first terminal device, a handover response to the first request.

[0011] In a seventh aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method in the third or fourth aspect.

[0012] 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

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

[0014] FIG. 1A illustrates an example of a network environment in which some example embodiments of the present disclosure may be implemented;

[0015] FIGS. IB and 1C illustrate examples of two sidelink (SL) resource allocation modes, Mode 1 and Mode 2, respectively, which can be used in some example embodiments of the present disclosure;

[0016] FIGS. ID to IF illustrate three examples of sidelink positioning scenarios in which some example embodiments of the present disclosure may be implemented;

[0017] FIGS. 1G and 1H illustrate two examples of inter-UE coordination scenarios in which some example embodiments of the present disclosure may be implemented;

[0018] FIG. 2 illustrates an example of a process flow for a terminal device handing over a PRU functionality to another terminal device in accordance with some example embodiments of the present disclosure; [0019] FIG. 3 illustrates an example of a process flow for a terminal device generating and updating a candidate list maintained by the terminal device in accordance with some example embodiments of the present disclosure;

[0020] FIG. 4 illustrates an example of a process flow for a terminal device informing other terminal devices of performing an eligibility test in accordance with some example embodiments of the present disclosure;

[0021] FIG. 5 illustrates another example of a process flow for a terminal device informing other terminal devices of performing an eligibility test in accordance with some example embodiments of the present disclosure;

[0022] FIG. 6 illustrates an example of a process flow for a terminal device transmitting an active PRU list to other terminal devices for updating candidate lists maintained by the terminal devices in accordance with some example embodiments of the present disclosure;

[0023] FIG. 7 illustrates another example of a process flow for a terminal device handing over a PRU functionality to another terminal device in accordance with some example embodiments of the present disclosure;

[0024] FIG. 8 illustrates a flowchart of a method implemented at a first terminal device in accordance with some example embodiments of the present disclosure;

[0025] FIG. 9 illustrates a flowchart of a method implemented at a second terminal device in accordance with some other embodiments of the present disclosure;

[0026] FIG. 10 illustrates a simplified block diagram of a device that is suitable for implementing some example embodiments of the present disclosure; and

[0027] FIG. 11 illustrates a block diagram of an example of a computer readable medium in accordance with some example embodiments of the present disclosure.

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

DETAILED DESCRIPTION

[0029] Principle of the present disclosure will now be described with reference to some example 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.

[0030] 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.

[0031] References in the present disclosure to “one embodiment,” “an embodiment,” “an example embodiment,” and the like indicate that the embodiment 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 are not necessarily referring to the same embodiment. 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.

[0032] It shall be understood that although the terms “first” and “second” etc. 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. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

[0033] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example 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, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/ or combinations thereof.

[0034] As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and

(ii) any portions of hardware processor(s) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit(s) and or processor(s), such as a microprocessor s) or a portion of a microprocessor s), that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

[0035] This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

[0036] As used herein, the term “communication network” refers to a network following any suitable communication standards, such as 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. Furthermore, 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 future fifth generation (5G) 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 of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

[0037] As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives 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), an evolved NodeB (eNodeB or eNB), a NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio header (RH), a remote radio head (RRH), a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology.

[0038] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), a Portable Subscriber Station, a Mobile Station (MS), or an Access Terminal (AT). The terminal device may include, but not limited to, a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones, a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, wireless endpoints, mobile stations, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), USB dongles, smart devices, 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 and applications (e.g., remote surgery), an industrial device and applications (e.g., 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.

[0039] In Uu-positioning, positioning reference unit (PRU) can be a device or network node with reliable location (for example, a road side unit, RSU for short, another UE, or the like) that can be activated on demand by the location management function (LMF) to perform specific positioning operations, for example, measurements and/or transmissions of specific positioning signals. For example, a PRU may be a 5G network entity that may be designated by the 5G NR network to assist with one or more positioning sessions. The following text box describes some non-restrictive introduction information of the PRU that can be used in some example embodiments of the present disclosure. However, it is noted that example embodiments of the present disclosure are not limited to current definitions or features of the PRU shown in the text box. Rather, example embodiments of the present disclosure can also be applicable to future PRUs or other similar units which may have definitions or features different from that of the current PRUs but have similar functions to current PRUs.

[0040] In Release 17 enhanced positioning, RANI deemed necessary and subsequently introduced the concept of positioning reference unit (PRU). The PRU may be an entity designated by the LMF to compute positioning-related correction and/or assistance data to be distributed to target UEs. The PRU data can be used by the target UEs to correct its own position measurements and/or compute more accurate location estimates.

[0041] In contrast to the anchor UE, the PRU may neither measure reference signals transmitted by the target UE nor transmit reference signals with the intention to be measured by the target UE. Instead, a UE in PRU state can be utilized as a reference unit that conducts similar measurements as the UEs in target or anchor state, which can then be used to correct the target UE’s original fix. Furthermore, a PRU can serve several target UEs, namely, the PRU can provide corrections of measurements of one or more SL positioning signals, where such signals may be used by one or more target UEs. In other words, a PRU’s activity may be linked to an SL positioning source, and not necessarily linked to a single target UE’s activity.

[0042] For example, PRU data may include cross-checking whether a given link is LOS or not, selecting a best TX PRS beam that a target UE should measure and thus removing the need for exhaustive beam sweeping by the target UE, and the like. The PRU data may also be used in infrastructure positioning, where the LMF carries out the refinement of the location estimate based on PRU data. In infrastructure positioning, the LMF can assign the PRU role to either a terminal entity or a network entity and can be in full control of the following: who can become a PRU, based on what criteria and for how long; what correction data the PRU is to compute; how often, how this data is used; which interfaces are used to transfer corrections to a target UE, and the like.

[0043] The LMF may thus activate and deactivate a relevant number of sufficiently accurate PRUs in a given geographical region so that the NR network strikes a right balance between two aspects. One aspect is the signaling overhead for transferring correction data among the network, PRU and target UEs. The other aspect is the computational power that the PRU uses to update more or less often the required correction data. However, in SL positioning (for example, in partial coverage or out-of-coverage), there is in principle no central entity aware of all PRU-capable terminals and target UEs in a geographical region. Therefore, it is not straightforward how to: (1) design and dimension the PRU pool of devices, (2) activate and deactivate the PRU functionalities of the devices, (3) trust the devices, and (4) enable the devices to transfer correction data to targeted SL peers, so that a balance between the above-mentioned two aspects is achieved.

[0044] Example embodiments of the present disclosure cover the above-mentioned gap by proposing a method that addresses the problems of PRU management, especially in SL positioning, thereby improving positioning performance of terminal devices in a communication network, for example, by allowing UEs to activate PRU functionalities without coordination by a central entity. More particularly, some example embodiments of the present disclosure propose a framework for transferring the PRU functionality among UEs, such as SL UEs. The framework can enable one or more target UEs (such as SL UEs) to finalize their ongoing positioning sessions (such as SL positioning sessions) involving PRU interactions. The framework can also ensure sufficient PRU presence for current and planned positioning sessions, such as SL positioning sessions, in case these sessions require PRU assistance. As a result, a target UE can be enabled to correct its own position measurements and/or compute more accurate location estimates. Principles and some example embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.

[0045] FIG. 1A illustrates an example of a network environment 100 in which some example embodiments of the present disclosure may be implemented. The network environment 100 may include a terminal device 110, a set of terminal devices 120, and a network device 105. The network device 105 may provide a wireless access cell through which the terminal device 110 and the set of terminal devices 120 may communicate with the network device 105. In some example embodiments, the network device 105 can be a gNB that provides 3 GPP New Radio (NR) cell. In other example embodiments, the network device 105 may be an eNB that provides an LTE cell. The air interfaces over which the terminal device 110, the set of terminal devices 120 and the network device 105 communicate may be compatible with 3 GPP technical specifications, such as those that define Fifth Generation (5G) NR system standards.

[0046] In the following descriptions, the terminal device 110 may be taken as an example terminal device that is performing the PRU functionality at a certain time point. In other words, the terminal device 110 functions as a PRU at the time point. In contrast, the set of terminal devices 120 may not performing the PRU functionality at the time point. That is, the set of terminal devices 120 are not PRUs at the time point. As depicted in FIG. 1, the set of terminal devices 120 include a terminal device 120-1, a terminal device 120-2, a terminal device 120-3, . . . , and a terminal device 120-N. It is noted that the number N can be any suitable natural number. It is to be understood that the number of network devices and terminal devices is only for the purpose of illustration without suggesting any limitations. The network environment 100 may include any suitable number of network devices and terminal devices adapted for implementing embodiments of the present disclosure. It is noted that some example embodiments of the present disclosure can be implemented without the presence of the network device 105.

[0047] The terminal device 110 and the set of terminal devices 120 may also communicate directly with one another over a sidelink interface. The sidelink interface may alternatively be referred to as a ProSe interface, device-to-device (D2D) interface, or a PC5 interface or reference point. In some example embodiments, the network environment 100 may be deployed within a vehicular communication system. In a vehicular communication system, the terminal device 110 and the set of terminal devices 120 may communicate with one another using cellular vehicle-to-everything (V2X) communications. V2X may involve vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), vehicle-to-network (VTN), or vehicle-to-pedestrian (V2P) communications. Thus, while FIG. 1 depicts the terminal device 110 and the set of terminal devices 120 as mobile phones, the terminal device 110 and the set of terminal devices 120 may be any type of user equipment. [0048] The terminal device 110 and the set of terminal devices 120 may communicate with one another using a sidelink resource pool. The sidelink resource pool may include a set of time/frequency resources for sidelink transmission or reception. The sidelink resource pool may be used for all unicast, groupcast, or broadcast communications for a given UE. In the frequency domain, the resource pool may include a plurality of subchannels, with each sub channel including a plurality of physical resource blocks (PRBs). In various example embodiments, a subchannel may include 10, 12, 15, 20, 25, 50, 75, or 100 PRBs, for example. In some example embodiments, the PRBs of a subchannel and the subchannels of a resource pool may be contiguous.

[0049] In the time domain, a sidelink resource pool may include a plurality of slots, which may be contiguous or noncontiguous. In some example embodiments, the slots for a sidelink resource pool may be configured by, for example, a bitmap transmitted by the network device 105 to indicate which slots are part of a sidelink resource pool. The bitmap may have a periodicity of 10,240 ms and a bitmap length between 10-160. In some example embodiments, a physical slot may include all slots including non-sidelink slots, while a logical slot may only include slots in the resource pool. For example, consider a 10-bit bitmap as follows: [1, 1, 0, 1, 1, 0, 1, 1, 1, 1], This bitmap indicates that 10 physical slots include 8 logical slots of a sidelink resource pool.

[0050] Resources of the sidelink may be allocated in a number of ways. For example, in a first mode (mode 1), the network device 105 may provide a sidelink grant to the terminal device 110 and the set of terminal devices 120. In a second mode (mode 2), a transmitting UE, for example, the terminal device 110, may sense a channel and select its own resources for transmission. Mode 2 resource allocation may include a plurality of operations including, for example: resource pool configuration; sensing; resource selection; and sidelink transmission.

[0051] Resource pool configuration may include the network device 105 providing the terminal device 110 and the set of terminal devices 120 with the configuration information via control signaling, for example, radio resource control (RRC) signaling. Additionally or alternatively, the configuration of the resource pool may include accessing predefined configuration information stored at the terminal device 110 and the set of terminal devices 120. After a UE is configured with a resource pool, a transmitting UE may perform a sensing procedure. Within a sensing window, the transmitting UE transmitting decode sidelink control information (SCI) to determine a data priority indication and resource reservation information. The transmitting UE can also measure a channel quality metric, such as reference signal received power (RSRP). The sidelink RSRP measurement may be based on physical sidelink control channel (PSCCH) demodulation reference signal (DMRS) or physical sidelink shared channel (PSSCH) DMRS.

[0052] Based on the sensing operation, the transmitting UE can select resources from within a resource selection window. The resources may be selected with the subchannel granularity in the frequency domain and a slot granularity in the time domain. The transmitting UE may identify candidate resources within the resource selection window. A resource of the resource selection window may be excluded from the candidate resources if it is reserved and its associated RSRP measurement is above a predetermined threshold. The transmitting UE may then select resources from the identified candidate resources. In some example embodiments, the selection may be randomized. The transmitting UE may then encode the sidelink data on the selected resources for transmission.

[0053] Communications in the network environment 100 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) and on 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, the communication may utilize any proper 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.

[0054] FIGS. IB and 1C illustrate examples of two sidelink resource allocation modes, Mode 1 and Mode 2, respectively, which can be used in some example embodiments of the present disclosure. In particular, FIG. IB shows the Mode 1 of sidelink resource allocation, whereas FIG. 1C shows the Mode 2 of sidelink resource allocation.

[0055] During 3 GPP Release 16, NR sidelink (SL) has been designed to facilitate a user equipment (UE) to communicate with other nearby UE(s) via direct/SL communication. Two resource allocation modes have been specified, and a SL transmitter (Tx) UE may be configured with one of them to perform its NR SL transmissions. These modes are denoted as NR SL mode 1 and NR SL mode 2. In mode 1, a sidelink transmission resource is assigned by the network (NW) to the SL Tx UE, while a SL Tx UE in mode 2 autonomously selects its SL transmission resources.

[0056] As shown in FIG. IB, in mode 1, where the network device (for example, gNB) 105 may be responsible for the SL resource allocation, and the configuration and operation can be similar to the one over the Uu interface. The MAC level details of this procedure can be found, for example, in section 5.8.3 of 38.321. More particularly, at 102, the terminal device 110 as the SL Tx UE may transmit sidelink scheduling request (SL-SR) to the network device 105. At 104, the network device 105 can indicate the resource allocation to the terminal device 110. At 106, the terminal device 110 may transmit a sidelink transmission (for example, PSCCH or PSSCH) to the terminal device 120-1. At 108, the terminal device 120-1 may transmit a sidelink feedback (for example, PSFCH) to the terminal device 110.

[0057] As shown in FIG. 1C, in mode 2, the SL UEs can perform autonomously the resource selection with the aid of a sensing procedure. More specifically, a SL Tx UE in NR SL mode 2 can first perform a sensing procedure over the configured SL transmission resource pool(s), in order to obtain the knowledge of the reserved resource(s) by other nearby SL Tx UE(s). Based on the knowledge obtained from sensing, the SL Tx UE may select resource(s) from the available SL resources, accordingly. In order for a SL UE to perform sensing and obtain the necessary information to receive a SL transmission, it may need to decode the sidelink control information (SCI). In release 16, the SCI associated with a data transmission may include a first stage SCI and a second stage SCI, and their contents are, for example, standardized in 3GPP TS 38.212.

[0058] FIGS. ID to IF illustrate three examples of sidelink positioning scenarios in which some example embodiments of the present disclosure may be implemented. In particular, FIG. ID shows an example of a sidelink absolute use case, FIG. IE shows an example of a sidelink relative use case, and FIG. IF shows an example of a sidelink assisted use case. In some examples, these sidelink positioning scenarios may be related to V2X and public safety. In addition, the use cases in FIGS. ID and IE may be out of coverage or sidelink only mode in coverage, and the use case in FIG. IF may be in coverage or patial coverage. [0059] In Release 18, positioning and especially sidelink positioning will be a significant study item/work item (SI/WI). The agreed way forward on positioning in 3GPP may include expanded and improved Positioning, with the following example areas; sidelink positioning/ranging; improved accuracy, integrity, and power efficiency; and RedCap positioning. In addition, there are some general observations. For example, the following are identified in terms of requirements (in roughly decreasing order of popularity): ranging, low-power positioning, accuracy enhancements (for example, down to cm -level), RAT- dependent positioning integrity, and latency reduction.

[0060] For ranging, the most identified technique by far may be sidelink-based. Low- power positioning is primarily targeted at RedCap devices but may also be applicable to other devices. Support for positioning in RRC IDLE may be the most identified technique here. The main techniques proposed for accuracy enhancement in general (apart from sidelink assistance) may be terrestrial carrier-phase positioning, PRS/SRS bandwidth aggregation, and the use of wide bandwidths at 60 GHz, which also implies the ability to transmit PRS in unlicensed spectrum, which is also seen as relevant for sidelink positioning.

[0061] Further, the proposed objectives may cover sidelink-based and sidelink-assisted positioning; low-power positioning, including for RedCap devices, including positioning in RRC IDLE as well as RRC INACTIVE; enhanced accuracy: carrier-phase positioning and PRS/SRS bandwidth aggregation; and PRS transmission in unlicensed spectrum, including 60 GHz. There can also be provided support of Mobile Termination (MT)-triggered small data transmission (SDT), for example, at least for a network-initiated positioning use case.

[0062] In some example embodiments of the present disclosure, the sidelink positioning may support three key use cases. As shown in FIG. ID, one such a use case may be termed as a Sidelink Absolute use case, which features position based on devices (known location) and absolute location known (for example, the longitude and the latitude). As shown in FIG. IE, another use case may be termed as a Sidelink Relative use case, which features distance and angle calculated by target and relative location known. As shown in FIG. IF, a further use case may be termed as a Sidelink Assisted use case, which features position calculated by Location Services (LCS) and absolute location known (for example, the longitude and the latitude).

[0063] FIGS. 1G and 1H illustrate two examples of inter-UE coordination scenarios in which some example embodiments of the present disclosure may be implemented. In particular, FIG. 1G shows an example in which the coordinating UE (UE A) is also the intended receiver of UE B’s transmission, and FIG. 1H shows an example in which the coordinating UE (UE A) is not the intended receiver of the UE B’s transmission.

[0064] In the approved 3 GPP Release 17 WI NR SL enh, SL resource allocation enhancement for mode 2 has been identified as one of the objectives, in which inter-UE coordination will be studied for enhanced reliability and reduced latency with the following:

[0065] In one of the inter-UE coordination scenarios (denoted in 3 GPP as Inter-UE Coordination Scheme 1) depicted in FIG. 1G, the UE A (RX-UE) may select the preferred SL transmit resource(s) (for example, according to its sensing) and recommend the selected resource(s) to UE B (TX-UE), where UE B can select its SL transmit resource by taking into account the resource(s) indicated by UE A and in addition performing its own sensing, for example, UE B may use or may not use the recommended resource(s) to transmit to UE A. Thus, by using the inter-UE coordination scheme, UE A may try to ensure there is no packet collision or strong interference over its selected resource(s), and thus the transmission from UE B to UE A can occur with high(er) reliability.

[0066] In another Inter-UE coordination scenario (denoted in 3 GPP as inter-UE Coordination Scheme 2) depicted in FIG. 1H, the UE A can monitor the transmissions taking place in the SL resource pool and every time a collision or half-duplex problem is detected (either in the past or in future resources) and then the UE A can inform the impacted UEs.

[0067] FIG. 2 illustrates an example of a process flow 200 for a terminal device handing over a PRU functionality to another terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process flow 200 will be described with reference to FIG. 1A. It would be appreciated that although the process flow 200 has been described in the network environment 100 of FIG. 1 A, this process flow may be likewise applied to other communication scenarios where a PRU functionality or a similar function is handed over from a terminal device to another terminal device.

[0068] In the process flow 200, the terminal device 110 transmits (205) a handover request 202 (or a request 202 for short) to the set of terminal devices 120, including the terminal device 120-1, the terminal device 120-2, . . ., and the terminal device 120-N. The handover request 202 can be used for a handover of a PRU functionality of the terminal device 110. In other words, the purpose of the handover request 202 is to hand over (or transfer) the PRU functionality of the terminal device 110 to one or more of the set of terminal devices 120. In general, the handover request 202 can be transmitted (205) by the terminal device 110 to the set of terminal devices 120 in various transmission manners. For example, the terminal device 110 can transmit (205) the handover request 202 to the set of terminal devices 120 via a broadcast sidelink message. As another example, the terminal device 110 may transmit (205) the handover request 202 to the set of terminal devices 120 via respective sidelink messages.

[0069] As mentioned with reference to FIG. 1 A, the set of terminal devices 120 may be not PRUs at the time point when the terminal device 110 is a PRU. Thus, before the terminal device 110 transmits (205) the handover request 202 to the set of terminal devices 120, the terminal device 110 may need to determine the set of terminal devices 120 from all the terminal devices with which the terminal device 110 can communicate, for example, via sidelink communications. There may be various ways for the terminal device 110 to determine the set of terminal devices 120. For example, the terminal device 110 can simply determine all the terminal devices available for a sidelink communication with the terminal device 110 as the set of terminal devices 120. In another example, the terminal device 110 may randomly select some of the terminal devices available for a sidelink communication with the terminal device 110 as the set of terminal devices 120. As a further example, the terminal device 110 can determine the set of terminal devices 120 based on a candidate list, which records candidate terminal devices available for providing the PRU functionality. Example embodiments related to the candidate list will be further detailed hereinafter with reference to FIG. 3.

[0070] The contents of the handover request 202 may have various forms in different example embodiments of the present disclosure. For example, in the simplest way, the handover request 202 can generally enquire whether each of the set of terminal device 120 can provide the PRU functionality instead of the terminal device 110. In some other examples, the handover request 202 may include one or more of the following contents: an ordered list of the set of terminal devices, a PRU configuration to be used by the set of terminal devices, and a condition to accept the handover request. In this way, the handover request 202 can provide more information to the set of terminal device 120, and thereby facilitating the possible handover of the PRU functionality between the terminal device 110 and one or more of the set of terminal device 120.

[0071] On the other side of communication, the set of terminal devices 120 receive the handover request 202 from the terminal device 110, respectively. More specifically, the terminal device 120-1 can receive (210-1) the handover request 202 from the terminal device 110. Similarly, the terminal device 120-2 may receive (210-2) the handover request 202 from the terminal device 110. Further, the terminal device 120-N may receive (210-N) the handover request 202 from the terminal device 110.

[0072] Upon receiving the handover request 202, the set of terminal devices 120 can transmit a set of respective handover responses 204-1 to 204-N to the terminal device 110 responsive to the handover request 202. For example, each of the handover responses may indicate whether a corresponding terminal device accepts the handover request 202 or not. More specifically, the terminal device 120-1 transmits (215-1) a handover response 204-1 to the terminal device 110. The handover response 204-1 is a reply made by the terminal device 120-1 to the handover request 202. In a similar way, the terminal device 120-2 transmits (215-2) a handover response 204-2 to the terminal device 110. The handover response 204-2 is a reply made by the terminal device 120-2 to the handover request 202. Further, the terminal device 120-N transmits (215-N) a handover response 204-N to the terminal device 110. The handover response 204-N is a reply made by the terminal device 120-N to the handover request 202.

[0073] Each of the set of terminal devices 120 may transmit different handover responses in different situations. Without loss of generality, the terminal device 120-1 will be taken as an example terminal device so as to describe these different handover responses. Other terminal devices among the set of terminal devices 120 can transmit a respective handover response in a similar manner. Generally, if the terminal device 120-1 is available for providing the PRU functionality instead of the terminal device 110, then the terminal device 120-1 may accept the handover request 202 and transmit the handover response 204-1 containing an accept indication. Otherwise, if the terminal device 120-1 is unavailable for providing the PRU functionality instead of the terminal device 110, then the terminal device 120-1 may deny the handover request 202 and transmit the handover response 204-1 containing a deny indication.

[0074] In some other example embodiments, it is assumed that the handover request 202 indicates a PRU configuration to be used by the terminal device 120-1. In this event, if the terminal device 120-1 has capability of providing the PRU functionality with the PRU configuration indicated in the handover request 202, then the terminal device 120-1 may transmit the handover response 204-1, which contains an indication that the terminal device 120-1 accepts the handover request 202. Otherwise, if the terminal device 120-1 does not have the capability of providing the PRU functionality with the PRU configuration indicated in the handover request 202, then the terminal device 120-1 can transmit the handover response 204-1, which may contain an indication that the terminal device 120-1 denies the handover request 202.

[0075] In some example embodiments, in addition to the handover request 202 from the terminal device 110, the terminal device 120-1 may receive another handover request from another terminal device other than the terminal device 110. For ease of description, this another terminal device can be termed as the terminal device 120-T. In addition, it is assumed that the handover request 202 can be termed as a first handover request 202, and the terminal device 120-1 receives a second handover request from the terminal device 120-T. The second handover request can be used for a handover of a PRU functionality of the terminal device 120-T to the terminal device 120-1. Further, it is assumed that the first handover request 202 indicates a first PRU configuration and the second handover request indicates a second PRU configuration.

[0076] In this event, the terminal device 120-1 may search for a broad PRU configuration covering both the first and second PRU configurations. In other words, the terminal device 120-1 can determine the presence or absence of such a broad PRU configuration that each of the first and second PRU configurations is part of the broad PRU configuration. If the terminal device 120-1 determines that the broad PRU configuration is present, then the terminal device 120-1 may transmit the handover response 204-1 containing a mapping table. The mapping table (or the table for short) can map PRU configurations determined by the terminal device 120-1 to terminal devices (including the terminal device 110) requesting the terminal device 120-1 to perform a PRU handover. Therefore, the mapping table may associate the terminal devices 110 and 120-T with the broad PRU configuration, so that the terminal devices 110 and 120-T can know that the broad PRU configuration is suggested by the terminal device 120-1 to replace both the first and second PRU configurations. Otherwise, if the terminal device 120-1 determines that the broad PRU configuration is not present, then the terminal device 120-1 may transmit the handover response 204-1 containing a compromise PRU configuration, which is a compromise between the first PRU configuration and the second PRU configuration. For example, the compromise PRU configuration may mean that the PRU to be provided by the terminal device 120-1 is to act for a shorter period of time than that indicated by a PRU configuration (such as the first PRU configuration or the second PRU configuration) in a handover request (such as the first handover request or the second handover request), or to provide a subset of assistance data indicated by the PRU configuration in the handover request, and so on.

[0077] To summarize the above possible contents of the handover responses 204-1 to 204- N, each of the set of handover responses 204 may contain the following contents from the perspective of the terminal device 110 as a receiving device of the handover responses 204. For example, a handover response can simply contain an indication that the handover request is accepted. On the contrary, a handover response may instead contain an indication that the handover request is denied. As another example, a handover response can contain a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover. The table may associate the terminal device 110 with a broad PRU configuration. Such a broad PRU configuration can cover the PRU configuration indicated in the handover request 202. In some other scenarios, a handover response may contain a compromise PRU configuration, which is compromised between the PRU configuration indicated in the handover request 202 and another PRU configuration. The another PRU configuration may be indicated in another handover request (namely the second handover request mentioned above) received by the terminal device 120-1 from another terminal device (namely the terminal device 120- T mentioned above). In this way, the handover responses 204 can provide useful information to the terminal device 110, and thereby facilitating the possible handover of the PRU functionality between the terminal device 110 and one or more of the set of terminal device 120.

[0078] Continuing with reference to FIG. 2, the terminal device 110 receives the set of respective handover responses 204-1 to 204-N (collectively referred to as the set of handover responses 204) from the set of terminal devices 120. For example, the terminal device 110 may receive (220-1) the handover response 204-1 from the terminal device 120-1. Similarly, the terminal device 110 can receive (220-2) the handover response 204-2 from the terminal device 120-2. Further, the terminal device 110 may receive (220-N) the handover response 204-N from the terminal device 120-N.

[0079] Based on the set of handover responses 204, the terminal device 110 determines (230) one or more destination terminal devices from the set of terminal devices 120, so as to hand over the PRU functionality from the terminal device 110 to these destination terminal devices. Accordingly, the destination terminal devices may refer to the transfer destinations of the handover of the PRU functionality, determined (230) by the terminal device 110. In other words, the terminal device 110 may select the destination terminal devices to activate their PRU functionalities instead of the terminal device 110. In an example, the terminal device 110 may determine (230) only one terminal device (such as the terminal device 120- 1) as the destination terminal device for handing over the PRU functionality. In another example, the terminal device 110 can determine (230) multiple terminal devices as destination terminal devices for handing over the PRU functionality, including the terminal device 120-1 and the terminal device 120-N, as shown in FIG. 2.

[0080] There may be various manners for the terminal device 110 to determine the destination terminal devices among the set of terminal devices 120. For example, the terminal device 110 may choose all the terminal devices that accept the handover request 202 as destination terminal devices. As another example, the terminal device 110 can randomly select one or more terminal devices among the terminal devices that accept the handover request 202 as destination terminal devices. As a further example, based on the set of handover responses 204, the terminal device 110 can determine either or both of predictive positioning performance after the handover and respective resource efficiencies of the set of terminal devices 120. Then, the terminal device 110 may select one or more destination terminal device from the set of terminal devices 120 based on either or both of the predictive positioning performance, the resource efficiencies, and positioning performance requirement. In this way, the terminal device 110 can ensure fine positioning performance in the network environment 100 after the handover.

[0081] In order to complete the handover of the PRU functionality from the terminal device 110 to the one or more destination terminal devices, the terminal device 110 may transmit a handover indication to the destination terminal devices for finalizing the handover of the PRU functionality. For example, in the case that the terminal device 120-1 and the terminal device 120-N are selected by the terminal device 110 as the destination terminal devices, then the terminal device 110 may transmit (235) a handover indication 206-1 of initiating the handover of the PRU functionality, and transmit (245) a handover indication 206-N of initiating the handover of the PRU functionality. It is noted that although FIG. 2 depicts the terminal device 110 as separately transmitting handover indications 206-1 and 206-N to the terminal devices 120-1 and 120-N, this depiction does not suggest any limitation on the scope of the present disclosure. In other example embodiments, the terminal device 110 can transmit a single message containing the handover indication, for example, via a broadcast transmission. In some example embodiments, the terminal device 110 can deactivate the PRU functionality after transmitting the handover indications 206-1 and 206-N. Accordingly, the terminal device 120-1 may receive (240) the handover indication 206-1 from the terminal device 110, and then initiate the handover of the PRU functionality. Also, the terminal device 120-N can receive (250) the handover indication 206-N from the terminal device 110, and then initiate the handover of the PRU functionality.

[0082] Through the process flow 200 of example embodiments of the present disclosure, positioning performance of terminal devices in a communication network can be improved, for example, by allowing UEs to activate PRU functionalities without coordination by a central entity. More particularly, through some example embodiments of process flow 200, a framework is proposed for transferring the PRU functionality among UEs, such as SL UEs. The framework can enable one or more target UEs (such as SL UEs) to finalize their ongoing positioning sessions (such as SL positioning sessions) involving PRU interactions. The framework can also ensure sufficient PRU presence for current and planned positioning sessions, such as SL positioning sessions, in case these sessions require PRU assistance. As a result, a target UE can be enabled to correct its own position measurements and/or compute more accurate location estimates.

[0083] In some example embodiments, for the purpose of completing the handover of the PRU functionality, the terminal device 120-1 may activate the PRU functionality of the terminal device 120-1 upon receiving (240) the handover indication 206-1, so as to provide the PRU functionality instead of the terminal device 110. Analogously, after receiving (250) the handover indication 206-N from the terminal device 110, the terminal device 120-N may activate the PRU functionality of the terminal device 120-N, so as to provide the PRU functionality instead of the terminal device 110. In this way, the PRU functionality of the terminal device 110 can be replaced with the PRU functionalities of the terminal devices 120- 1 and 120-N without adverse impact on the positioning performance in the network. [0084] In some situations, there may be some terminal devices among the set of terminal device 120, which terminal devices accept the handover request 202 from the terminal device 110 but are not determined by the terminal device 110 as destination terminal devices. Therefore, the handover of the PRU functionality is actually cancelled for such terminal devices. In some example embodiments, these terminal devices can be informed of the cancellation of the handover of the PRU functionality in either an explicit way or an implicit way. As an example of the explicit manner and with reference to FIG. 2, it is assumed that from the set of terminal devices 120 and based on the set of handover responses 204, the terminal device 110 determines the terminal device 120-2 for avoiding handing over the PRU functionality from the terminal device 110 to the terminal device 120-2. In other words, the handover response 204-2 provided by the terminal device 120-2 may indicate that the terminal device 120-2 accepts the handover request 202, but the terminal device 110 decides not to hand over the PRU functionality to the terminal device 120-2. For example, the reason may be that positioning performance after the PRU functionality is handed over to the terminal device 120-2 is lower than the case in which the PRU functionality is handed over to the terminal device 120-1 or 120-N.

[0085] In this situation, the terminal device 110 can transmit (255) to the terminal device 120-2 a handover cancel indication 208 of cancelling the handover. Upon receiving (260) the handover cancel indication 208 from the terminal device 110, the terminal device 120-2 may keep the PRU functionality of the terminal device 120 inactive. In other words, the terminal device 120-2 may not provide the PRU functionality to substitute for the PRU functionality of the terminal device 110. In this explicit manner, the terminal device 120-2 can be informed of the handover cancel indication 208 as soon as possible, thereby improving the efficiency of the process flow 200.

[0086] As an example of the implicit manner, upon transmitting (215-2) the handover response 204-2 to the terminal device 110, the terminal device 120-2 can start a timer for expecting the handover of the PRU functionality. If the timer expires and there no handover indication from the terminal device 110, then the terminal device 120-2 may determine that the handover of the PRU functionality is cancelled and thus can keep the PRU functionality of the terminal device 120-2 inactive. By this implicit way, the terminal device 110 does not need to transmit a handover cancel indication, thereby reducing the singling overhead.

[0087] In some example embodiments, before the terminal device 110 transmits (205) the handover request 202 to the set of terminal devices 120, the terminal device 110 may determine whether the handover of the PRU functionality is required. If the terminal device 110 determines that the handover is required, then the first terminal device 110 may transmit (205) the handover request 202 to the set of terminal devices 120. In this way, the terminal device 110 can avoid unnecessary handover of the PRU functionality, thereby saving communication resources in the network environment 100 and processing or battery resources in the terminal device 110 and the set of terminal devices 120.

[0088] In determining whether the handover is needed, the terminal device 110 may consider various possible factors. For example, a factor to be considered may be expiration of a PRU activity timer of the first terminal device. In addition, another possible factor to be considered may be available power level below a threshold at the terminal device 110. As another example, another possible factor to be considered failing to meet a position integrity requirement of the first terminal device. As a further example, another possible factor to be considered may be a need of the first terminal device to serve a higher urgency traffic. In addition, another possible factor to be considered may be an explicit request by another terminal device or serving network device to hand over the PRU functionality. Further, another possible factor to be considered may be that a terminal device is performing PRU functionality for a sidelink positioning session, determining that a terminal device has high positioning integrity. Moreover, another possible factor to be considered may be that a terminal device has low uncertainty level on its own location. Furthermore, another possible factor to be considered may be that mobility of a terminal device is similar to the first terminal device and the handover is helpful for load sharing. It is noted that the terminal device 110 can take into account any one or more of the above factors when determining whether the handover is required. With taking one or more of these factors into consideration, the decision made by the terminal device 110 as to whether the handover is required can be more reasonable.

[0089] As described above, in some example embodiments, the terminal device 110 can determine the set of terminal devices 120 based on a candidate list. More specifically, in order to determine the set of terminal devices 120 to which the handover request is to be transmitted, the terminal device 110 may maintain a candidate list of candidate terminal devices available for the PRU functionality. In other words, the candidate list indicates candidate terminal devices that are determined by the terminal device 110 as being available for the PRU functionality. In such example embodiments, the terminal device 110 can select the set of terminal devices 120 from the candidate list, so that the handover request may be more efficient and thereby reducing the signaling overhead of the handover request transmission.

[0090] FIG. 3 illustrates an example of a process flow 300 for a terminal device generating and updating a candidate list maintained by the terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process flow 300 will be described with reference to FIG. 1 A. It would be appreciated that although the process flow 300 has been described in the network environment 100 of FIG. 1A, this process flow may be likewise applied to other communication scenarios where a candidate list is generated and updated.

[0091] In the process flow 300, the terminal device 110 may generate (305) the candidate list which records candidate terminal devices available for the PRU functionality. In some example embodiments, since the candidate list indicates terminal devices capable of providing the PRU functionality, the terminal device 110 can generate (305) the candidate list based on detection of terminal devices available for the PRU functionality. For example, the candidate list may be populated when the terminal device 110 hears a SL PRU configuration/activation message, including PRU specific inter-UE coordination (IUC) messages. Alternatively or additionally, the candidate list may be populated when the terminal device 110 observes a UE to have completed its localization, when the UE is configured to transition to PRU state upon completion of its localization. This is particularly beneficial in scenarios where the initiation of SL positioning session with certain anchor/PRU UEs requires the UE to accept to act as a PRU upon completion of the session. Alternatively or additionally, the candidate list may be populated when the terminal device 110 permits or provisions PRU configurations, or assists another UE to act as a PRU to other target UE(s). In this way, the candidate list can be generated in an efficient way.

[0092] Continuing with reference to FIG. 3, if the terminal device 110 determines (310) that the candidate list needs to be updated, then the terminal device 110 may perform an update of the candidate list. In order to perform the update of the candidate list, the terminal device 110 can transmit (315) an update request 302 to the candidate terminal devices in the candidate list. The update request 302 can be used for an update of the candidate list maintained by the terminal device 110. It is noted that the candidate terminal devices in the candidate list are depicted in FIG. 3, for example, as terminal devices 130-1 to 130-X, collectively referred to as candidate terminal devices 130. In some scenarios, the set of terminal devices 120 shown in FIGS. 1 and 2 may be selected from and thus be part of the candidate terminal devices 130. Thus, the number X may be a natural number greater than or equal to the number N. Accordingly, in FIG. 3, the terminal device 110 can transmit (315) the update request 302 to the terminal devices 130-1 to 130-X. In some example embodiments, the update request 302 can be transmitted via a single broadcast message. In some other example embodiments, the update request 302 may be transmitted via separate messages for the respective terminal devices 130-1 to 130-X.

[0093] On the receiving side, the terminal devices 130-1 to 130-X may receive the update request 302 from the terminal device 110. In particular, the terminal device 130-1 can receive (320-1) the update request 302 from the terminal device 110. Similarly, the terminal device 130-2 can receive (320-2) the update request 302 from the terminal device 110. Further, the terminal device 130-X can receive (320-X) the update request 302 from the terminal device 110.

[0094] Then, the terminal devices 130-1 to 130-X may transmit respective PRU functionality information to the terminal device 110. In some example embodiments, the PRU functionality information may include one or more of the following types of information. One type of information may be PRU willingness, for example, duration for which they can serve as PRUs, time-frequency (time slots, PRBs) resources that they can measure, or the like. Another type of information may be location estimate and associated certainty and integrity level of the location estimate, location source, for example, Global Navigation Satellite System (GNSS), NR Uu, or the like. A third type of information can be mobility type, for example, direction, velocity, trajectory, and so on. A fourth type of information can be correction data capability, for example, line-of-sight (LoS) indication or probability, SL-Angle of Departure (AoD) uncertainty, and so on. A fifth type of information may be from whom and how many other PRU refresh requests has received within the last T seconds. A sixth type of information can be whether they have been, or currently are PRUs and for which sources they are providing corrections. A seventh type of information may be whether the PRU candidate is associated with a twin PRU that can replace the PRU candidate in case of abrupt unavailability, for example, PRUs that have identified themselves to experience similar mobility and radio conditions, such as devices moving together in a UE group, such as within a train.

[0095] More specifically, the terminal device 130-1 can transmit (325-1) PRU functionality information 304-1 of the terminal device 130-1 to the terminal device 110. Similarly, the terminal device 130-2 can transmit (325-2) PRU functionality information 304-2 of the terminal device 130-2 to the terminal device 110. Further, the terminal device 130-X can transmit (325-X) PRU functionality information 304-X of the terminal device 130-X to the terminal device 110.

[0096] On the other side of the communication, the terminal device 110 can receive PRU functionality information of the respective candidate terminal devices 130. More specifically, from the terminal device 130-1, the terminal device 110 may receive (330-1) the PRU functionality information 304-1 of the terminal device 130-1. Similarly, from the terminal device 130-2, the terminal device 110 may receive (330-2) the PRU functionality information 304-2 of the terminal device 130-2. Further, from the terminal device 130-X, the terminal device 110 may receive (330-X) the PRU functionality information 304-X of the terminal device 130-X. Then, the terminal device 110 may update (335) the candidate list based on the PRU functionality information of the candidate terminal devices 130. Through the process flow 300, the terminal device 110 can increase efficiency and accuracy rate of the determination of the set of terminal devices 120, thereby optimizing the process flow 200.

[0097] With the generated or updated candidate list, the terminal device 110 can then select the set of terminal devices 120 from the candidate terminal devices 130 recorded in the candidate list. In this way, the possibility that the set of terminal devices 120 accept the handover request 202 can be increased, thereby making the process flow 200 more efficient. In general, the terminal device 110 may have various ways to perform the selection. For example, the terminal device 110 can select candidate terminal devices with more recent PRU functionality information as the set of terminal devices 120. As another example, the terminal device 110 may randomly select some candidate terminal devices from the candidate list. In a further example, the terminal device 110 may select candidate terminal devices which pass an eligibility test as the set of terminal devices 120. Such example embodiments will be further detailed below with reference to FIG. 4.

[0098] FIG. 4 illustrates an example of a process flow 400 for a terminal device informing other terminal devices of performing an eligibility test in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process flow 400 will be described with reference to FIG. 1A. It would be appreciated that although the process flow 400 has been described in the network environment 100 of FIG. 1 A, this process flow may be likewise applied to other communication scenarios where an eligibility test is informed and performed. [0099] In the process flow 400, the terminal device 110 may determine (405) an eligibility test for a subset of candidate terminal devices in the candidate list. It is noted that the subset of candidate terminal devices in the candidate list are depicted in FIG. 4, for example, as terminal devices 140-1 to 140-M, collectively referred to as the subset of candidate terminal devices 140. The subset of terminal devices 140 may be selected from and thus be part of the candidate terminal devices 130 in the candidate list shown in FIG. 3, and thus the number M may be a nature number less than or equal to the number X. On the other hand, in some example embodiments, since the set of terminal device 120 are determined as a portion of subset of terminal devices 140, which portion passes the eligibility test, the number M may be greater than or equal to the number N.

[00100] Continuing with reference to FIG. 4, the terminal device 110 may transmit (410) an indication 402 of the eligibility test to the subset of candidate terminal devices 140. On the one hand, the indication 402 may indicate test items of the eligibility test. For example, the test items can include measuring a sidelink positioning reference signal (SL-PRS) and calculating a subset of correction data, such as LoS probability. On the other hand, the indication 402 can also function as a trigger for performing the eligibility test. Accordingly, the subset of candidate terminal devices 140 can receive the indication 402 from the terminal device 110. In particular, the terminal device 140-1 can receive (415-1) the indication 402 from the terminal device 110. Similarly, the terminal device 140-2 can receive (415-2) the indication 402 from the terminal device 110. Further, the terminal device 140-M can receive (415-M) the indication 402 from the terminal device 110.

[00101] Upon receiving the indication 402 from the terminal device 110, the subset of candidate terminal devices 140 may perform the eligibility test, respectively. More specifically, the terminal device 140-1 can perform (420-1) the eligibility test to obtain a test result 404-1. Similarly, the terminal device 140-2 can perform (420-2) the eligibility test to obtain a test result 404-2. Further, the terminal device 140-M can perform (420-M) the eligibility test to obtain a test result 404-M.

[00102] Afterwards, the subset of candidate terminal devices 140 can transmit their respective test results to the terminal device 110. More specifically, the terminal device 140-1 can transmit (425-1) the test result 404-1 to the terminal device 110. Similarly, the terminal device 140-2 can transmit (425-2) the test result 404-2 to the terminal device 110. Further, the terminal device 140-M can transmit (425-M) the test result 404-M to the terminal device 110. [00103] Accordingly, the terminal device 110 may receive respective test results 404-1 to 404-M (collectively referred to as the test results 404) from the subset of candidate terminal devices 140. More specifically, the terminal device 110 can receive (430-1) the test result 404-1 from the terminal device 140-1. Similarly, the terminal device 110 can receive (430- 2) the test result 404-2 from the terminal device 140-1. Further, the terminal device 110 can receive (430-M) the test result 404-M from the terminal device 140-M. Then, the terminal device 110 can determine (430) the set of terminal devices 120 based on the test results 404. For example, the terminal device 110 may select terminal devices with better test results as the set of terminal devices 120. Through the process flow 400, the terminal device 110 can ensure that the selected set of terminal devices 120 are eligible for the handover of the PRU functionality.

[00104] FIG. 5 illustrates another example of a process flow for a terminal device informing other terminal devices of performing an eligibility test in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process flow 500 will be described with reference to FIG. 1A. It would be appreciated that although the process flow 500 has been described in the network environment 100 of FIG. 1 A, this process flow may be likewise applied to other communication scenarios where an eligibility test is informed and performed.

[00105] The example embodiment of FIG.5 is depicted and will be described from perspectives of a current PRU 502 and a candidate PRU 504. More particularly, the current PRU 502 may request one or more candidate PRUs (including the candidate PRU 504) to perform a PRU eligibility test. Then, based on the test results, the current PRU 502 can decide the best next PRU or PRUs.

[00106] In the process flow 500, the current PRU 502 may create (505) an eligibility test, which may include a sidelink positioning reference signal (SL-PRS) configuration and a subset of correction data for multiple tests, such as test 1 to test X. In some example embodiments, the current PRU 502 can assess a list of candidates PRUs and selects a subset of those for performing the PRU eligibility test.

[00107] Next, the current PRU 502 may transfer (510) the eligibility test to the selected candidate PRUs. For example, the current PRU sends a “PRU eligibility test” configuration to the selected PRUs or UEs. The test configuration message can contain a SL-PRS to measure and a subset of correction data for the candidate to compute, for example, LoS probability.

[00108] Afterwards, the selected candidate PRUs can perform the eligibility test as instructed and reply with test results containing the requested correction data. For example, the candidate PRU 504 can perform (515) the eligibility test, which may include measuring a SL-PRS and computing required correction data. For example, the test result reported by the candidate PRU 504 may include correction data 1 for test 1, correction data 2 for test 2, . . . , and correction data X for test X.

[00109] Then, the current PRU 502 can evaluate (525) the test results reported by the candidate PRU 504. In particular, the current PRU 502 evaluates the correction data and if the reported correction matches within a certain margin with its own correction data, then the candidate PRU can be deemed as PRU eligible. For example, in case the correction data is LoS probability, then the current PRU 502 may check if a difference between the candidate LoS and the current LoS is smaller than a threshold, for example, 0.1. If the judging result is positive, the current PRU 502 may conclude that the candidate PRU 504 observes the same channel towards the SL-PRS source and it is thus PRU eligible.

[00110] FIG. 6 illustrates an example of a process flow 600 for a terminal device transmitting an active PRU list to other terminal devices for updating candidate lists maintained by the terminal devices in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process flow 600 will be described with reference to FIG.

1 A. It would be appreciated that although the process flow 600 has been described in the network environment 100 of FIG. 1A, this process flow may be likewise applied to other communication scenarios where a terminal device transmits an active PRU list to other terminal devices for updating candidate lists maintained by the terminal devices.

[00111] In the process flow 600, if the terminal device 110 completes (605) the handover of the PRU functionality from the terminal device 110 to one or more destination terminal devices, the terminal device 110 may determine (610) an active PRU list 602 of terminal devices providing the PRU functionality through the handover of the PRU functionality. In other words, the active PRU list 602 may record the new terminal devices known by the terminal device 110 as being active PRUs after the handover of the PRU functionality. Then, the terminal device 110 can transmit (615) the active PRU list 602 to the candidate terminal devices 130 for an update of respective candidate lists maintained by the candidate terminal devices 130. It is noted that in the example embodiment in FIG. 6, the active PRU list 602 is transmitted to all the candidate terminal devices 130 in the candidate list, regardless of whether a candidate terminal device is selected by the terminal device 110 as one of the set of terminal device 120.

[00112] Accordingly, the candidate terminal devices 130 can receive the active PRU list 602 from the terminal device 110. Specifically, the terminal device 130-1 may receive (620-1) the active PRU list 602 from the terminal device 110. Similarly, the terminal device 130-2 may receive (620-2) the active PRU list 602 from the terminal device 110. Further, the terminal device 130-X may receive (620-X) the active PRU list 602 from the terminal device 110.

[00113] Upon receiving the active PRU list 602 from the terminal device 110, the candidate terminal devices 130 may update their candidate list, respectively, because the active PRU list 602 can indicate the new terminal devices known by the terminal device 110 as being active PRUs after the handover of the PRU functionality. More specifically, the terminal device 130-1 can update (625-1) a candidate list maintained by the terminal device 130-1 based on the active PRU list 202. The candidate list indicates candidate terminal devices determined by the terminal device 130-1 as being available for the PRU functionality. Similarly, the terminal device 130-2 can update (625-2) a candidate list maintained by the terminal device 130-2 based on the active PRU list 202. The candidate list indicates candidate terminal devices determined by the terminal device 130-2 as being available for the PRU functionality. More specifically, the terminal device 130-X can update (625-X) a candidate list maintained by the terminal device 130-X based on the active PRU list 202. The candidate list indicates candidate terminal devices determined by the terminal device 130-X as being available for the PRU functionality.

[00114] FIG. 7 illustrates another example of a process flow 700 for a terminal device handing over a PRU functionality to another terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the process flow 700 will be described with reference to FIG. 1 A. It would be appreciated that although the process flow 700 has been described in the network environment 100 of FIG. 1A, this process flow may be likewise applied to other communication scenarios where a PRU functionality or a similar function is handed over from a terminal device to another terminal device. [00115] In some example embodiments, a current PRU 703 in FIG. 7 may be the terminal device 110 in FIG. 1, a candidate PRU-1 707 may be the terminal device 120-1 in FIG. 1, a candidate PRU-2 709 may be the terminal device 120-2 in FIG. 1, a candidate PRU-3 711 may be the terminal device 120-3 in FIG. 1, and a target UE 701 may be the terminal device 120-N in FIG. 1. In some other example embodiments, the target UE 701 can be any one of terminal devices shown or not shown in FIG. 1, the current PRU 703 can be any one of terminal devices shown or not shown in FIG. 1, the candidate PRU-1 707 can be any one of terminal devices shown or not shown in FIG. 1, the candidate PRU-2 709 can be any one of terminal devices shown or not shown in FIG. 1, and the candidate PRU-3 711 can be any one of terminal devices shown or not shown in FIG. 1.

[00116] In general, example embodiments in FIG. 7 can propose a SL positioning framework for a PRU functionality transfer and retuning. Specifically, the example embodiments describe how a SL UE (referred as UE for short) which wants or needs to relinquish its PRU function, referred as current PRU henceforth, and hands over the PRU function to at least one of another UEs, called candidate PRUs.

[00117] It is noted that a candidate PRU may be a SL UE which has any one of the following. (1) The SL UE implicitly agreed to take up the role of a PRU as a result of triggering its own positioning session (for example, SL, Uu or non-NR based sessions). In other words, a SL UE which becomes a target for a SL positioning session will transition to a PRU state after its localization is finalized. (2) The SL UE explicitly agreed, for example, upon a PRU request coming from a target UE, another PRU, the serving gNB or the like to take up the role of a PRU for a given duration, under explicitly indicated configurations and conditions (namely the agreed conditions by the candidate PRU with the requested node) such as: type of correction data it can compute; time-frequency resources (slots, PRBs) which it can monitor; and PRU availability duration. (3) The SL UE explicitly indicated its availability to become a PRU, for example, via a SL broadcast.

[00118] In the process flow 700, the current PRU 703 transmits (705) PRU correction data

702 to the target UE 701. Accordingly, the target UE 701 receives (710) the PRU correction data from the current PRU 703 for positioning of the target UE 701. Next, the current PRU

703 creates and maintains (715) a candidate PRU list. For example, each active PRU (current PRU) may maintain a list of candidate PRUs, namely, the UEs that are available for PRU role but are not selected to act as such. [00119] In some examples, this list may be populated whenever the current PRU hears a SL PRU configuration/activation message, including PRU specific inter-UE coordination (IUC) messages. This list may be populated whenever the current PRU observes a UE to have completed its localization, when the UEs are configured to transition to PRU state upon completion of its localization. This is particularly beneficial in scenarios where the initiation of SL positioning session with certain anchor/PRU UEs requires the UE to accept to act as a PRU upon completion of the session. This list may be populated whenever the current PRU permits or provisions PRU configurations/assists another UE to act as a PRU to other target UE(s).

[00120] Then, the current PRU 703 performs (720) a candidate PRU update assessment. For example, the current PRU 703 assesses whether it needs to refresh its own candidate PRU list and in case of positive conclusion (for example, too old entries), it generates a refresh request for candidate PRUs. Afterwards, the current PRU 703 transmits (725) a candidate PRU refresh request 704 to the candidate PRUs. Accordingly, the candidate PRU-1 707 receives (730-1) the candidate PRU refresh request 704 from the current PRU 703. The candidate PRU-2 709 receives (730-2) the candidate PRU refresh request 704 from the current PRU 703. The candidate PRU-3 711 receives (730-3) the candidate PRU refresh request 704 from the current PRU 703.

[00121] This transmission may be realized by a broadcast SL message requesting all nearby UEs (candidate PRUs 707, 709, 711 and so on) to indicate one or more of the below information: (1) PRU willingness, for example, duration for which they can serve as PRUs, time-frequency (time slots, PRBs) resources that they can measure, or the like; (2) location estimate and associated certainty and integrity level of the location estimate, location source for example, GNSS, NR Uu, and so on; (3) mobility type e.g. direction, velocity, trajectory, and so on; (4) correction data capability, for example, LoS indication or probability, SL-AoD uncertainty, and so on; (5) from whom and how many other PRU refresh requests has received within the last T seconds; (6) whether they have been, or currently are PRUs and for which sources they are providing corrections; and (7) whether the PRU candidate is associated with a twin PRU that can replace the PRU candidate in case of abrupt unavailability, for examples, PRUs that have identified themselves to experience similar mobility and radio conditions, such as devices moving together in a UE group, such as within a train. [00122] Then, the candidate PRU-1 707 transmits (735-1) a candidate PRU refresh response 706-1 to the current PRU 703. The candidate PRU-2 709 transmits (735-2) a candidate PRU refresh response 706-2 to the current PRU 703. The candidate PRU-3 711 transmits (735-3) a candidate PRU refresh response 706-3 to the current PRU 703. Accordingly, the current PRU 703 receives (740-1) the candidate PRU refresh response 706-1 from the candidate PRU-1 707. The current PRU 703 receives (740-2) the candidate PRU refresh response 706-2 from the candidate PRU-2 709. The current PRU 703 receives (740-3) the candidate PRU refresh response 706-3 from the candidate PRU-3 711.

[00123] In particular, each candidate PRU may reply with the above list and the current PRU updates (refreshes) its candidate UE list. Note that the candidate PRU may, prior to sending the above list, refresh its own position information. Examples includes correcting its most recent location fix using mobility information, requiring assistance from the serving gNB, for example, generating a localization request, and if available, acquiring its non-NR position such as GNSS.

[00124] Afterwards, the current PRU 703 triggers (745) a PRU handover. For example, after the list refresh is finalized, the current PRU assesses whether a PRU functionality transfer is required. This may be triggered based on the following factors: (1) a set of conditions which the current PRU UE has met, for example, a PRU activity timer has expired or the available power level has been dropped below a critical threshold ( power saving constraints); (2) its position integrity requirements cannot be ensured anymore, for example, the PRU detects severe interference or the PRU detects high uncertainty levels on its own location estimate; (3) current PRU UE needs to serve higher urgency traffic; (4) explicit request by another UE or serving gNB to handover the PRU role; (5) candidate PRU is already acting as PRU for other SL positioning sessions and hence may have the ability to multiplex its correction data transmission for resource efficiency; (6) candidate PRU is observed to have high positioning integrity and/or low uncertainty level on its own location; and (7) candidate PRU’s mobility is observed to be similar to the current PRU and the current PRU decides to do temporary handover for such as load sharing.

[00125] Next, the current PRU 703 transmits (750) a PRU handover request 708 to the candidate PRUs. Accordingly, the candidate PRU-1 707 receives (755-1) the PRU handover request 708 from the current PRU 703. The candidate PRU-2 709 receives (755- 2) the PRU handover request 708 from the current PRU 703. The candidate PRU-3 711 receives (755-3) the PRU handover request 708 from the current PRU 703. Specifically, if the current PRU 703 concludes that a handover is required, it assesses the available pool of candidate PRUs. The current PRU 703 may generate an ordered list of PRU candidates and sends a handover request to the selected candidates, by attaching the ordered list.

[00126] In an alternative embodiment, the assessment of PRU eligibility may involve an eligibility test that the current PRU is triggering for a selected subset of candidates. For example, it may request the candidate to compute correction data for one/or more active SL- PRS resources and report such correction data. If the candidate’s correction matches the current PRU’s own correction data, then the handover is triggered.

[00127] In some example embodiments, the handover request may also further include the following contents: (1) the PRU configuration(s) to be used by the candidate PRU should the candidate PRU accept the request, and the configuration may also include a minimum duration in which the candidate UE is required to serve as a PRU; (2) condition to accept the handover request, for example, correction data to be within a certain indicated range upon performing an indicated PRU handover suitability test, wherein the PRU handover test may involve a simple PRU correction computation.

[00128] Each candidate PRU may assess the PRU request. In some example embodiments, the candidate may receive multiple PRU configuration requests from different PRU handover requestors. In this case, the candidate can assess whether the multiple requests can be addressed with a single PRU configuration, or they create a conflict. In case the multiple requests are addressed with a single PRU configuration, the candidate can assign the requestor (current PRU) IDs to the PRU configuration. In case of conflict, the candidate may resolve the conflict, for example, by choosing a compromise configuration. Upon resolution, the candidate may reply with an ACK/NACK and/or with the compromise PRU configuration and/or the mapping table that associates the requestor IDs with the PRU configurations.

[00129] Thus, the candidate PRU-1 707 transmits (760-1) a PRU handover accept 712-1 to the current PRU 703. The candidate PRU-2 709 transmits (760-2) a PRU handover accept 712-2 to the current PRU 703. The candidate PRU-3 711 transmits no handover response. Accordingly, the current PRU 703 receives (765-1) the PRU handover accept 712-1 from the candidate PRU-1 707. The current PRU 703 receives (765-2) the PRU handover accept 712-2 from the candidate PRU-1 711. [00130] Afterwards, the current PRU 703 performs (770) a PRU handover response assessment. Specifically, the current PRU 703 can assess all replies and selects and activates one or more UEs to handover the PRU role to. The selection may be done on the basis of a) positioning performance, and b) resource efficiency. Positioning performance relates to the accuracy achieved after the handover of PRU. The selection may be thus done by comparing the PRU uncertainty level for each option, along with mobility type and correction data capability. Resource efficiency relates to the amount of resources consumed for the PRU usage. As such, a candidate PRU which serves multiple target UEs with the same resources is preferable over a PRU which only serves one target UE, such that the overall resource efficiency is higher in the former case. The selection process can take as input the positioning requirements in terms of performance, such that the selected candidate is the candidate that satisfies the requirements and achieves the most efficient resource usage.

[00131] Then, the current PRU 703 transmits (775) a PRU handover indication 714 to the candidate PRU-1 707. Thus, the candidate PRU-1 707 receives (780) the PRU handover indication 714 from the current PRU 703. Then, the candidate PRU-1 707 transmits (795) PRU correction data 718 to the target UE 701. The target UE 701 receives (797) the PRU correction data 718 from the candidate PRU-1 707 for positioning of the target UE 701.

[00132] It is noted that the candidate PRUs that have responded to the PRU request but not chosen for handover may be indicated with a PRU handover cancel message to not to expect PRU handover. For example, the current PRU 703 transmits (785) a PRU handover cancel 716 to the candidate PRU-2 709 and the candidate PRU-3 711, the candidate PRU-2 709 receives (790-2) the PRU handover cancel 716 from the current PRU 703, and the candidate PRU-3 711 receives (790-3) the PRU handover cancel 716 from the current PRU 703. Alternatively, a candidate PRU may be configured (for example, in the PRU handover request) with timer within which the PRU handover is expected from the current PRU to the candidate PRU. Upon expiry of the timer, the candidate PRU 703 can consider itself out of the current PRU handover.

[00133] In an alternative embodiment, the current PRU 703 may create the list of new active PRUs, and indicate the active PRU list to all candidate PRUs (both the selected and nonselected ones). The benefit of this approach is that the non-selected candidates can refresh their own candidate list. [00134] In summary, the proposed framework provided through the process flow 700 defines the following new functionalities and signals as part of the SL positioning framework. A current PRU may maintain a list of candidate PRUs, which can be refreshed based on: (1) detecting ongoing nearby PRU (re)selections, where the configurations are realized over SL; (2) testing available candidate UEs for PRU eligibility; in other words, the current PRU initiates an eligibility test that the candidates need to perform, and only upon receiving the test results from the candidates, and assessment of the results, the current PRU initiates the PRU transfer; and (3) pre-agreements with other UEs to transfer PRU role to; this refers to the situation in which a SL UE has implicitly or explicitly indicated its availability for performing PRU functions.

[00135] In addition, a current PRU can assess the need for PRU functionality transfer and trigger the transfer by engaging in a SL exchange with a set of candidate PRUs available on the list. The SL exchange may target the establishment and pre-agreement of a minimal PRU functionality that each candidate can ensure. In other words, the PRU functionality may be modified by the candidates and approved by the current PRU, if the candidate does not support the current PRU configuration.

[00136] Furthermore, a current PRU, based on the outcome of the pre-agreement, can select and activate the best UE(s) from the responding candidates and finalize the PRU functionality transfer. Subsequently, it may release the waiting candidates from the PRU transfer.

[00137] The proposed framework enables one or more target UE(s) to finalize their ongoing SL positioning session that involves PRU interaction without any interruption in getting PRU assistance (for example, position correction data). This is achieved by ensuring sufficient PRU presence for current and planned SL positioning sessions, in case the sessions require PRU assistance. As a result, the target UE is enabled to correct its own position measurements, and/or compute more accurate and/or faster location estimates.

[00138] In some example embodiments, if a candidate PRU receives multiple PRU handover requests indicating different PRU configurations, the candidate PRU may need to resolve PRU conflicting configurations. For example, the different requests may target: a) same SL-PRS resources but require different correction data with potentially different refresh rates; and b) different SL-PRS resources. The candidate PRU can assess the different correction data required on each SL-PRS resource and whether it can produce each data with the required refresh rate. Then, the candidate PRU may generate a compromise correction capability for each SL-PRS resource. An example is shown in the below table.

[00139] Note that Correction_data(prs_idx, type idx) can denote a correction data, which is requested for SL-PRS indexed by prs idx and of type denoted by type idx. Also note that in the above table, the correction list per SL-PRS resource may contain none of all required corrections, all of all required corrections, or some of all required corrections.

[00140] FIG. 8 illustrates a flowchart 800 of a method implemented at a first terminal device in accordance with some example embodiments of the present disclosure. For the purpose of discussion, the method 800 will be described from the perspective of the terminal device 110 with reference to FIG. 1.

[00141] At block 810, the first terminal device 110 transmits, to a set of terminal devices 120, a request for a handover of a PRU functionality of the terminal device 110. At block 820, the first terminal device 110 receives a set of respective handover responses from the set of terminal devices 120. At block 830, the first terminal device 110 determines, from the set of terminal devices and based on the set of handover responses, a second terminal device 120-1 for handing over the PRU functionality from the first terminal device to the second terminal device. At block 840, the first terminal device 110 transmits, to the second terminal device 120-1, a handover indication of initiating the handover. [00142] In some example embodiments, the method 800 further comprises: selecting the set of terminal devices from a candidate list of candidate terminal devices available for the PRU functionality.

[00143] In some example embodiments, selecting the set of terminal devices comprises: determining an eligibility test for a subset of candidate terminal devices in the candidate list; transmitting an indication of the eligibility test to the subset of candidate terminal devices; receiving respective test results from the subset of candidate terminal devices; and determining the set of terminal devices based on the test results.

[00144] In some example embodiments, the method 800 further comprises: generating the candidate list based on detection of terminal devices available for the PRU functionality; and in response to determining that the candidate list needs to be updated, performing an update of the candidate list.

[00145] In some example embodiments, performing the update of the candidate list comprises: transmitting an update request to the candidate terminal devices in the candidate list; receiving, from the candidate terminal devices, PRU functionality information of the respective candidate terminal devices; and updating the candidate list based on the PRU functionality information.

[00146] In some example embodiments, determining the second terminal device comprises: determining, based on the set of handover responses, at least one of predictive positioning performance after the handover and respective resource efficiencies of the set of terminal devices; and selecting the second terminal device from the set of terminal devices based on at least one of the predictive positioning performance, the resource efficiencies, and positioning performance requirement.

[00147] In some example embodiments, the method 800 further comprises: determining, from the set of terminal devices and based on the set of handover responses, a third terminal device for avoiding handing over the PRU functionality from the first terminal device to the third terminal device; and transmitting, to the third terminal device, a handover cancel indication of cancelling the handover.

[00148] In some example embodiments, the method 800 further comprises: determining whether the handover of the PRU functionality is required; and in response to determining that the handover is required, transmitting the request for the handover to the set of terminal devices. [00149] In some example embodiments, determining that the handover is required is based on at least one of the following: expiration of a PRU activity timer of the first terminal device; available power level below a threshold at the first terminal device; failing to meet a position integrity requirement of the first terminal device; a need of the first terminal device to serve a higher urgency traffic; an explicit request by another terminal device or serving network device to hand over the PRU functionality; determining that a terminal device is performing PRU functionality for a sidelink positioning session; determining that a terminal device has high positioning integrity; determining that a terminal device has low uncertainty level on its own location; and determining that mobility of a terminal device is similar to the first terminal device and the handover is helpful for load sharing.

[00150] In some example embodiments, the request for the handover comprises at least one of the following: an ordered list of the set of terminal devices; a PRU configuration to be used by the set of terminal devices; and a condition to accept the request for the handover.

[00151] In some example embodiments, each of the set of handover responses comprises one of the following: an indication that the request for the handover is accepted; an indication that the request for the handover is denied; a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover, the table associating the first terminal device with a broad PRU configuration covering a PRU configuration indicated in the request for the handover; and a compromise PRU configuration between the PRU configuration indicated in the request for the handover and another PRU configuration indicated in another request for a handover received by the second terminal device from a third terminal device.

[00152] In some example embodiments, the method 800 further comprises: in response to completion of the handover, determining an active PRU list indicating terminal devices providing the PRU functionality through the handover; and transmitting the active PRU list to the candidate terminal devices for an update of respective candidate lists maintained by the candidate terminal devices.

[00153] In some example embodiments, the first terminal device and the set of terminal devices are communicated via sidelink communications.

[00154] FIG. 9 illustrates a flowchart 900 of a method implemented at a second terminal device in accordance with some other embodiments of the present disclosure. For the purpose of discussion, the method 900 will be described from the perspective of the terminal device 120-1 with reference to FIG. 1.

[00155] At block 910, the second terminal device 120-1 receives, from a first terminal device 110, a first request for a handover of a PRU functionality of the first terminal device 110. At block 920, the second terminal device 120-1 transmits, to the first terminal device 110, a handover response to the first request.

[00156] In some example embodiments, transmitting the handover response comprises: if the second terminal device has capability of providing the PRU functionality with a first PRU configuration indicated in the first request, transmitting the handover response containing an indication that the second terminal device accepts the request; otherwise transmitting the handover response containing an indication that the second terminal device denies the request.

[00157] In some example embodiments, the method 900 further comprises: receiving, from a third terminal device, a second request for a handover of the PRU functionality of the third terminal device; and determining presence or absence of a broad PRU configuration covering a first PRU configuration indicated in the first request and a second PRU configuration indicated in the second request.

[00158] In some example embodiments, transmitting the handover response comprises: in response to determining the presence of the broad PRU configuration, transmitting the handover response containing a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover, the table associating the first and third terminal devices with the broad PRU configuration; and in response to determining the absence of the broad PRU configuration, transmitting the handover response containing a compromise PRU configuration between the first PRU configuration and the second PRU configuration.

[00159] In some example embodiments, the method 900 further comprises: receiving an indication of an eligibility test from the first terminal device; performing the eligibility test to obtain a test result; and transmitting the test result to the first terminal device.

[00160] In some example embodiments, the method 900 further comprises: receiving, from the first terminal device, an update request for an update of a candidate list maintained by the first terminal device, the candidate list indicating candidate terminal devices available for the PRU functionality; and transmitting, to the first terminal device, PRU functionality information of the second terminal device. [00161] In some example embodiments, the method 900 further comprises: in response to receiving, from the first terminal device, a handover indication of initiating the handover, activating the PRU functionality of the second terminal device.

[00162] In some example embodiments, the method 900 further comprises: in response to receiving, from the first terminal device, a handover cancel indication of cancelling the handover, keeping the PRU functionality of the second terminal device inactive.

[00163] In some example embodiments, the method 900 further comprises: in response to transmitting the handover response to the first terminal device, starting a timer for expecting the handover; and in response to expiration of the timer, keeping the PRU functionality of the second terminal device inactive.

[00164] In some example embodiments, the request for the handover comprises at least one of the following: an ordered list of a set of terminal devices including the second terminal device; a PRU configuration to be used by the second terminal device; and a condition to accept the request for the handover.

[00165] In some example embodiments, the method 900 further comprises: receiving, from the first terminal device, an active PRU list indicating terminal devices providing the PRU functionality through the handover; and updating a candidate list maintained by the second terminal device based on the active PRU list, the candidate list indicating candidate terminal devices available for the PRU functionality.

[00166] In some example embodiments, the first and second terminal devices are communicated via sidelink communications.

[00167] In some example embodiments, an apparatus capable of performing the method 800 (for example, the terminal device 110) may comprise means for performing the respective steps of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

[00168] In some example embodiments, the apparatus comprises: means for transmitting, at a first terminal device to a set of terminal devices, a request for a handover of a PRU functionality of the first terminal device; means for receiving a set of respective handover responses from the set of terminal devices; means for determining, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and means for transmitting, to the second terminal device, a handover indication of initiating the handover.

[00169] In some example embodiments, the apparatus further comprises: means for selecting the set of terminal devices from a candidate list of candidate terminal devices available for the PRU functionality.

[00170] In some example embodiments, the means for selecting the set of terminal devices comprises: means for determining an eligibility test for a subset of candidate terminal devices in the candidate list; means for transmitting an indication of the eligibility test to the subset of candidate terminal devices; means for receiving respective test results from the subset of candidate terminal devices; and means for determining the set of terminal devices based on the test results.

[00171] In some example embodiments, the apparatus further comprises: means for generating the candidate list based on detection of terminal devices available for the PRU functionality; and means for in response to determining that the candidate list needs to be updated, performing an update of the candidate list.

[00172] In some example embodiments, the means for performing the update of the candidate list comprises: means for transmitting an update request to the candidate terminal devices in the candidate list; means for receiving, from the candidate terminal devices, PRU functionality information of the respective candidate terminal devices; and means for updating the candidate list based on the PRU functionality information.

[00173] In some example embodiments, the means for determining the second terminal device comprises: means for determining, based on the set of handover responses, at least one of predictive positioning performance after the handover and respective resource efficiencies of the set of terminal devices; and means for selecting the second terminal device from the set of terminal devices based on at least one of the predictive positioning performance, the resource efficiencies, and positioning performance requirement.

[00174] In some example embodiments, the apparatus further comprises: means for determining, from the set of terminal devices and based on the set of handover responses, a third terminal device for avoiding handing over the PRU functionality from the first terminal device to the third terminal device; and means for transmitting, to the third terminal device, a handover cancel indication of cancelling the handover. [00175] In some example embodiments, the apparatus further comprises: means for determining whether the handover of the PRU functionality is required; and means for in response to determining that the handover is required, transmitting the request for the handover to the set of terminal devices.

[00176] In some example embodiments, determining that the handover is required is based on at least one of the following: expiration of a PRU activity timer of the first terminal device; available power level below a threshold at the first terminal device; failing to meet a position integrity requirement of the first terminal device; a need of the first terminal device to serve a higher urgency traffic; an explicit request by another terminal device or serving network device to hand over the PRU functionality; determining that a terminal device is performing PRU functionality for a sidelink positioning session; determining that a terminal device has high positioning integrity; determining that a terminal device has low uncertainty level on its own location; and determining that mobility of a terminal device is similar to the first terminal device and the handover is helpful for load sharing.

[00177] In some example embodiments, the request for the handover comprises at least one of the following: an ordered list of the set of terminal devices; a PRU configuration to be used by the set of terminal devices; and a condition to accept the request for the handover.

[00178] In some example embodiments, each of the set of handover responses comprises one of the following: an indication that the request for the handover is accepted; an indication that the request for the handover is denied; a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover, the table associating the first terminal device with a broad PRU configuration covering a PRU configuration indicated in the request for the handover; and a compromise PRU configuration between the PRU configuration indicated in the request for the handover and another PRU configuration indicated in another request for a handover received by the second terminal device from a third terminal device.

[00179] In some example embodiments, the apparatus further comprises: means for in response to completion of the handover, determining an active PRU list indicating terminal devices providing the PRU functionality through the handover; and means for transmitting the active PRU list to the candidate terminal devices for an update of respective candidate lists maintained by the candidate terminal devices. [00180] In some example embodiments, the first terminal device and the set of terminal devices are communicated via sidelink communications.

[00181] In some example embodiments, the apparatus further comprises means for performing other steps in some example embodiments of the method 800. In some example 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 apparatus.

[00182] In some example embodiments, an apparatus capable of performing the method 900 (for example, the terminal device 120-1) 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.

[00183] In some example embodiments, the apparatus comprises: means for receiving, at a second terminal device from a first terminal device, a first request for a handover of a PRU functionality of the first terminal device; and means for transmitting, to the first terminal device, a handover response to the first request.

[00184] In some example embodiments, the means for transmitting the handover response comprises: means for if the second terminal device has capability of providing the PRU functionality with a first PRU configuration indicated in the first request, transmitting the handover response containing an indication that the second terminal device accepts the request; otherwise means for transmitting the handover response containing an indication that the second terminal device denies the request.

[00185] In some example embodiments, the apparatus further comprises: means for receiving, from a third terminal device, a second request for a handover of the PRU functionality of the third terminal device; and means for determining presence or absence of a broad PRU configuration covering a first PRU configuration indicated in the first request and a second PRU configuration indicated in the second request.

[00186] In some example embodiments, the means for transmitting the handover response comprises: means for in response to determining the presence of the broad PRU configuration, transmitting the handover response containing a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover, the table associating the first and third terminal devices with the broad PRU configuration; and means for in response to determining the absence of the broad PRU configuration, transmitting the handover response containing a compromise PRU configuration between the first PRU configuration and the second PRU configuration.

[00187] In some example embodiments, the apparatus further comprises: means for receiving an indication of an eligibility test from the first terminal device; means for performing the eligibility test to obtain a test result; and means for transmitting the test result to the first terminal device.

[00188] In some example embodiments, the apparatus further comprises: means for receiving, from the first terminal device, an update request for an update of a candidate list maintained by the first terminal device, the candidate list indicating candidate terminal devices available for the PRU functionality; and means for transmitting, to the first terminal device, PRU functionality information of the second terminal device.

[00189] In some example embodiments, the apparatus further comprises: means for in response to receiving, from the first terminal device, a handover indication of initiating the handover, activating the PRU functionality of the second terminal device.

[00190] In some example embodiments, the apparatus further comprises: means for in response to receiving, from the first terminal device, a handover cancel indication of cancelling the handover, keeping the PRU functionality of the second terminal device inactive.

[00191] In some example embodiments, the apparatus further comprises: means for in response to transmitting the handover response to the first terminal device, starting a timer for expecting the handover; and means for in response to expiration of the timer, keeping the PRU functionality of the second terminal device inactive.

[00192] In some example embodiments, the request for the handover comprises at least one of the following: an ordered list of a set of terminal devices including the second terminal device; a PRU configuration to be used by the second terminal device; and a condition to accept the request for the handover.

[00193] In some example embodiments, the apparatus further comprises: means for receiving, from the first terminal device, an active PRU list indicating terminal devices providing the PRU functionality through the handover; and means for updating a candidate list maintained by the second terminal device based on the active PRU list, the candidate list indicating candidate terminal devices available for the PRU functionality. [00194] In some example embodiments, the first and second terminal devices are communicated via sidelink communications.

[00195] In some example embodiments, the apparatus further comprises means for performing other steps in some example embodiments of the method 900. In some example 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 apparatus.

[00196] FIG. 10 illustrates a simplified block diagram of a device 1000 that is suitable for implementing some example embodiments of the present disclosure. The device 1000 may be provided to implement the communication device, for example the terminal device 110, the terminal devices 120, or the network device 105 as shown in FIG. 1 A. As shown, the device 1000 includes one or more processors 1010, one or more memories 1020 coupled to the processor 1010, and one or more communication modules 1040 coupled to the processor 1010.

[00197] The communication module 1040 is for bidirectional communications. The communication module 1040 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

[00198] The processor 1010 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 1000 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.

[00199] The memory 1020 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 1024, an electrically programmable read only memory (EPROM), a flash memory, a hard disk, a compact disc (CD), a digital video disk (DVD), and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 1022 and other volatile memories that will not last in the power-down duration. [00200] A computer program 1030 includes computer executable instructions that are executed by the associated processor 1010. The program 1030 may be stored in the ROM 1024. The processor 1010 may perform any suitable actions and processing by loading the program 1030 into the RAM 1022.

[00201] The embodiments of the present disclosure may be implemented by means of the program 1030 so that the device 1000 may perform any process of the disclosure as discussed with reference to FIGS. 2 to 7. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

[00202] In some example embodiments, the program 1030 may be tangibly contained in a computer readable medium which may be included in the device 1000 (such as in the memory 1020) or other storage devices that are accessible by the device 1000. The device 1000 may load the program 1030 from the computer readable medium to the RAM 1022 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like.

[00203] FIG. 11 illustrates a block diagram of an example of a computer readable medium 1100 in accordance with some example embodiments of the present disclosure. The computer readable medium 1100 has the program 1030 stored thereon. It is noted that although the computer readable medium 1100 is depicted in form of CD or DVD in FIG. 11, the computer readable medium 1100 may be in any other form suitable for carry or hold the program 1030.

[00204] 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 representations, it is to be understood that the block, apparatus, system, technique or method 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.

[00205] 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 method 800 or 900 as described above with reference to FIG. 8 or 9. 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.

[00206] 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.

[00207] In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

[00208] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer 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 computer 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. [00209] 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.

[00210] Although the present disclosure has been described in languages 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

WHAT IS CLAIMED IS:

1. A first terminal device comprising: at least one processor; and at least one memory storing computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the first terminal device to: transmit, to a set of terminal devices, a request for a handover of a positioning reference unit (PRU) functionality of the first terminal device; receive a set of respective handover responses from the set of terminal devices; determine, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and transmit, to the second terminal device, a handover indication of initiating the handover.

2. The first terminal device of claim 1, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to: select the set of terminal devices from a candidate list of candidate terminal devices available for the PRU functionality.

3. The first terminal device of claim 2, wherein the first terminal device is caused to select the set of terminal devices by: determining an eligibility test for a subset of candidate terminal devices in the candidate list; transmitting an indication of the eligibility test to the subset of candidate terminal devices; receiving respective test results from the subset of candidate terminal devices; and determining the set of terminal devices based on the test results.

4. The first terminal device of claim 2, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to: generate the candidate list based on detection of terminal devices available for the PRU functionality; and in response to determining that the candidate list needs to be updated, perform an update of the candidate list.

5. The first terminal device of claim 4, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to perform the update of the candidate list by: transmitting an update request to the candidate terminal devices in the candidate list; receiving, from the candidate terminal devices, PRU functionality information of the respective candidate terminal devices; and updating the candidate list based on the PRU functionality information.

6. The first terminal device of claim 1, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to determine the second terminal device by: determining, based on the set of handover responses, at least one of predictive positioning performance after the handover and respective resource efficiencies of the set of terminal devices; and selecting the second terminal device from the set of terminal devices based on at least one of the predictive positioning performance, the resource efficiencies, and positioning performance requirement.

7. The first terminal device of claim 1, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to: determine, from the set of terminal devices and based on the set of handover responses, a third terminal device for avoiding handing over the PRU functionality from the first terminal device to the third terminal device; and transmit, to the third terminal device, a handover cancel indication of cancelling the handover.

8. The first terminal device of claim 1, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to: determine whether the handover of the PRU functionality is required; and in response to determining that the handover is required, transmit the request for the handover to the set of terminal devices.

9. The first terminal device of claim 8, wherein the first terminal device is caused to determine that the handover is required based on at least one of the following: expiration of a PRU activity timer of the first terminal device; available power level below a threshold at the first terminal device; failing to meet a position integrity requirement of the first terminal device; a need of the first terminal device to serve a higher urgency traffic; an explicit request by another terminal device or serving network device to hand over the PRU functionality; determining that a terminal device is performing PRU functionality for a sidelink positioning session; determining that a terminal device has high positioning integrity; determining that a terminal device has low uncertainty level on its own location; and determining that mobility of a terminal device is similar to the first terminal device and the handover is helpful for load sharing.

10. The first terminal device of claim 1, wherein the request for the handover comprises at least one of the following: an ordered list of the set of terminal devices; a PRU configuration to be used by the set of terminal devices; and a condition to accept the request for the handover.

11. The first terminal device of claim 1, wherein each of the set of handover responses comprises one of the following: an indication that the request for the handover is accepted; an indication that the request for the handover is denied; a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover, the table associating the first terminal device with a broad PRU configuration covering a PRU configuration indicated in the request for handover; and a compromise PRU configuration between the PRU configuration indicated in the request for the handover and another PRU configuration indicated in another request for a handover received by the second terminal device from a third terminal device.

12. The first terminal device of claim 2, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the first terminal device to: in response to completion of the handover, determine an active PRU list indicating terminal devices providing the PRU functionality through the handover; and transmit the active PRU list to the candidate terminal devices for an update of respective candidate lists maintained by the candidate terminal devices.

13. The first terminal device of claim 1, wherein the first terminal device and the set of terminal devices are communicated via sidelink communications.

14. A second terminal device comprising: at least one processor; and at least one memory storing computer program codes; the at least one memory and the computer program codes are configured to, with the at least one processor, cause the second terminal device to: receive, from a first terminal device, a first request for a handover of a positioning reference unit (PRU) functionality of the first terminal device; and transmit, to the first terminal device, a handover response to the first request.

15. The second terminal device of claim 14, wherein the second terminal device is caused to transmit the handover response by: if the second terminal device has capability of providing the PRU functionality with a first PRU configuration indicated in the first request, transmitting the handover response containing an indication that the second terminal device accepts the request; otherwise transmitting the handover response containing an indication that the second terminal device denies the request.

16. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: receive, from a third terminal device, a second request for a handover of the PRU functionality of the third terminal device; and determine presence or absence of a broad PRU configuration covering a first PRU configuration indicated in the first request and a second PRU configuration indicated in the second request.

17. The second terminal device of claim 16, wherein the second terminal device is caused to transmit the handover response by: in response to determining the presence of the broad PRU configuration, transmitting the handover response containing a table mapping PRU configurations determined by the second terminal device to terminal devices requesting the second terminal device to perform a PRU handover, the table associating the first and third terminal devices with the broad PRU configuration; and in response to determining the absence of the broad PRU configuration, transmitting the handover response containing a compromise PRU configuration between the first PRU configuration and the second PRU configuration.

18. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: receive an indication of an eligibility test from the first terminal device; perform the eligibility test to obtain a test result; and transmit the test result to the first terminal device.

19. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: receive, from the first terminal device, an update request for an update of a candidate list maintained by the first terminal device, the candidate list indicating candidate terminal devices available for the PRU functionality; and transmit, to the first terminal device, PRU functionality information of the second terminal device.

20. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: in response to receiving, from the first terminal device, a handover indication of initiating the handover, activate the PRU functionality of the second terminal device.

21. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: in response to receiving, from the first terminal device, a handover cancel indication of cancelling the handover, keep the PRU functionality of the second terminal device inactive.

22. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: in response to transmitting the handover response to the first terminal device, start a timer for expecting the handover; and in response to expiration of the timer, keep the PRU functionality of the second terminal device inactive.

23. The second terminal device of claim 14, wherein the request for the handover comprises at least one of the following: an ordered list of a set of terminal devices including the second terminal device; a PRU configuration to be used by the second terminal device; and a condition to accept the request for the handover.

24. The second terminal device of claim 14, wherein the at least one memory and the computer program codes are further configured to, with the at least one processor, cause the second terminal device to: receive, from the first terminal device, an active PRU list indicating terminal devices providing the PRU functionality through the handover; and update a candidate list maintained by the second terminal device based on the active PRU list, the candidate list indicating candidate terminal devices available for the PRU functionality.

25. The second terminal device of claim 14, wherein the first and second terminal devices are communicated via sidelink communications.

26. A method comprising: transmitting, at a first terminal device to a set of terminal devices, a request for a handover of a positioning reference unit (PRU) functionality of the first terminal device; receiving a set of respective handover responses from the set of terminal devices; determining, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and transmitting, to the second terminal device, a handover indication of initiating the handover.

27. A method comprising: receiving, at a second terminal device from a first terminal device, a first request for a handover of a positioning reference unit (PRU) functionality of the first terminal device; and transmitting, to the first terminal device, a handover response to the first request.

28. An apparatus comprising: means for transmitting, at a first terminal device to a set of terminal devices, a request for a handover of a positioning reference unit (PRU) functionality of the first terminal device; means for receiving a set of respective handover responses from the set of terminal devices; means for determining, from the set of terminal devices and based on the set of handover responses, a second terminal device for handing over the PRU functionality from the first terminal device to the second terminal device; and means for transmitting, to the second terminal device, a handover indication of initiating the handover.

29. An apparatus comprising: means for receiving, at a second terminal device from a first terminal device, a first request for a handover of a positioning reference unit (PRU) functionality of the first terminal device; and means for transmitting, to the first terminal device, a handover response to the first request.

30. A non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of claim 26 or 27.