Handover of positioning reference unit function

Abstract

Example embodiments of the present disclosure relate to a terminal device handing over a positioning reference unit (PRU) function to one or more other terminal devices. In an example method, a first terminal device sends a request to a group of terminal devices, the request for a handover of a PRU function of the first terminal device. The first terminal device receives a corresponding set of handover responses from a set of terminal devices. And based on the group of handover responses, the first terminal device determines a second terminal device from the group of terminal devices, the second terminal device being configured to handover the PRU function from the first terminal device to the second terminal device. And the first terminal device sends a handover instruction for initiating handover to the second terminal device. According to the embodiment of the invention, the positioning performance of the terminal equipment in a communication network can be improved.

Description

Technical Field

[0001] Example embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to terminal devices, methods, apparatuses, and computer-readable storage media for handing over positioning reference unit (PRU) functionality from one terminal device to one or more other terminal devices. Background Art

[0002] In communication technology, continuous evolution is ongoing to provide efficient and reliable solutions for utilizing wireless communication networks. Each new generation has its own technical challenges to handle the different situations and processes required to connect and serve devices connected to wireless networks. In order to meet the demand for wireless data services that has increased since the deployment of the fourth generation (4G) communication system, efforts have been made to develop improved fifth generation (5G) or pre-5G communication systems. The new communication system can support various types of service applications for terminal devices.

[0003] Positioning of end devices or mobile devices may be useful or necessary for many applications including emergency calling, navigation, direction finding, asset tracking, Internet services and V2X applications. To improve the positioning performance of end devices, there are some unresolved issues in Sidelink (SL) positioning in 5G New Radio (NR) that will be studied in the near future. Some discussions have been made on the requirements, use cases and scenarios of SL positioning that are being considered for the Rel-18 specification work phase. SL positioning will be an enabler for many use cases, most notably public safety and vehicular applications as well as industrial and commercial applications. Summary of the invention

[0004] In general, example embodiments of the present disclosure provide a solution for handing over PRU functionality from one terminal device to one or more other terminal devices.

[0005] In a first aspect, a first terminal device is provided. The first terminal device includes at least one processor; and at least one memory, wherein the at least one memory stores computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, enable the first terminal device to: send a request to a group of terminal devices, requesting a handover of a certain PRU function of the first terminal device; receive a corresponding group of handover responses from the group of terminal devices; determine a second terminal device from the group of terminal devices based on the group of handover responses, and the second terminal device is used to handover the PRU function from the first terminal device to the second terminal device; and send a handover indication to initiate the handover to the second terminal device.

[0006] In a second aspect, a second terminal device is provided. The second terminal device includes at least one processor; and at least one memory, wherein the at least one memory stores computer program code; the at least one memory and the computer program code are configured to, together with the at least one processor, enable the second terminal device to: receive a first request from a first terminal device, wherein the first request is for handover of a PRU function of the first terminal device; and send a handover response to the first request to the first terminal device.

[0007] In a third aspect, a method performed by a first terminal device is provided. The method includes: sending a request to a group of terminal devices at the first terminal device, requesting a handover of a PRU function of the first terminal device; receiving a corresponding group of handover responses from the group of terminal devices; determining a second terminal device from the group of terminal devices based on the group of handover responses, the second terminal device being used to handover the PRU function from the first terminal device to the second terminal device; and sending a handover indication to initiate the handover to the second terminal device.

[0008] In a fourth aspect, a method performed by a second terminal device is provided, the method comprising: receiving a first request from a first terminal device at the second terminal device, the first request being for handover of a PRU function of the first terminal device; and sending a handover response to the first request to the first terminal device.

[0009] In a fifth aspect, a device is provided. The device includes: a component for sending a request to a group of terminal devices at a first terminal device, requesting a handover of a PRU function for the first terminal device; a component for receiving a corresponding group of handover responses from the group of terminal devices; a component for determining a second terminal device from the group of terminal devices based on the group of handover responses, the second terminal device being used to handover the PRU function from the first terminal device to the second terminal device; and a component for sending a handover indication to initiate the handover to the second terminal device.

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

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

[0012] It should be understood that the invention summary is not intended to identify the key or essential features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become easily understood 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] Figure 1A shows an example of a network environment in which some example embodiments of the present disclosure may be implemented;

[0015] Figure 1B and Figure 1C Examples of two side link (SL) resource allocation modes, Mode 1 and Mode 2, respectively, which may be used in some example embodiments of the present disclosure;

[0016] Figures 1D to 1F Three examples of sidelink positioning scenarios are shown in which some example embodiments of the present disclosure may be implemented;

[0017] Figure 1G and Figure 1H Two examples of inter-UE coordination scenarios are shown in which some example embodiments of the present disclosure may be implemented;

[0018] Figure 2 An example of a process flow for a terminal device to hand over a PRU function to another terminal device according to some example embodiments of the present disclosure is shown;

[0019] Figure 3 An example of a process flow for a terminal device to generate and update a candidate list maintained by the terminal device according to some example embodiments of the present disclosure is shown;

[0020] Figure 4 An example of a process flow for a terminal device to notify other terminal devices to perform a qualification test according to some example embodiments of the present disclosure is shown;

[0021] Figure 5 Another example of a process flow for a terminal device to notify other terminal devices to perform a qualification test according to some example embodiments of the present disclosure is shown;

[0022] Figure 6 An example of a process flow for a terminal device to send an active PRU list to other terminal devices to update a candidate list maintained by the terminal device according to some example embodiments of the present disclosure is shown;

[0023] Figure 7 Another example of a process flow for a terminal device to hand over a PRU function to another terminal device according to some example embodiments of the present disclosure is shown;

[0024] Figure 8 A flowchart of a method implemented at a first terminal device according to some example embodiments of the present disclosure is shown;

[0025] Fig. 9 A flowchart of a method implemented at a second terminal device according to some other embodiments of the present disclosure is shown;

[0026] Fig.10 shows a simplified block diagram of a device suitable for implementing some example embodiments of the present disclosure; and

[0027] Fig.11 A block diagram illustrating an example of a computer readable medium according to some example embodiments of the present disclosure is shown.

[0028] Throughout the drawings, the same or similar reference numerals refer to the same or similar elements. DETAILED DESCRIPTION

[0029] The principles of the present disclosure will now be described with reference to some example embodiments. It should be understood that these embodiments are described only for illustrative purposes and to help those skilled in the art understand and implement the present disclosure without implying any limitation on the scope of the present disclosure. The embodiments described herein can be implemented in various ways different from the ways 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 skill in the art to which this disclosure belongs.

[0031] References in this disclosure to "one embodiment," "an embodiment," "an example embodiment," etc. indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Furthermore, when a particular feature, structure, or characteristic is described in conjunction with an embodiment, it is considered to be within the knowledge of those skilled in the art to affect such feature, structure, or characteristic in conjunction with other embodiments, whether or not explicitly described.

[0032] It should be understood that although the terms "first", "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 element. For example, without departing from the scope of the exemplary embodiment, the first element may be referred to as the second element, and similarly, the second element may be referred to as the first element. As used herein, the term "and / or" includes any and all combinations of one or more of the listed terms.

[0033] The terms used herein are only used for the purpose of describing specific embodiments and are not intended to limit the exemplary embodiments. As used herein, the singular forms "a", "an", and "the" are also intended to include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "comprise", "including", "having", "having", "including" and / or "comprising" when used herein specify the presence of features, elements and / or components, etc., but do not exclude 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 circuit implementation only (such as implementation only in analog and / or digital circuits) and (b) a combination of hardware circuitry and software, such as (where applicable): (i) a combination of analog and / or digital hardware circuits and software / firmware and (ii) any portion of a hardware processor (including a digital signal processor) with software, software and memory that work together to enable a device such as a mobile phone or server to perform various functions, and (c) A hardware circuit and / or processor that requires software (eg, firmware) for operation, such as a microprocessor or portion of a microprocessor, but the software may not be present when not required for operation.

[0035] This definition of circuitry applies to all uses of the term in this application, including in any claims. As another example, as used in this application, the term circuitry also covers an implementation of only a hardware circuit or processor (or multiple processors) or a 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 a particular claim element), a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in a server, cellular network device, or other computing or network device.

[0036] As used herein, the term "communication network" refers to a network that complies with any suitable communication standard, such as New Radio (NR), Long Term Evolution (LTE), Advanced LTE (LTE-A), Wideband Code Division Multiple Access (WCDMA), High Speed ​​Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. In addition, the communication between the terminal equipment and the network equipment in the communication network can be performed according to any suitable generation communication protocol, including but not limited to the first generation (1G), second generation (2G), 2.5G, 2.75G, third generation (3G), fourth generation (4G), 4.5G, fifth generation (5G) communication protocol and / or any other protocol currently known or developed in the future. The embodiments of the present disclosure can be applied to various communication systems. In view of the rapid development of communication, there are of course communication technologies and systems of future types that can implement the present disclosure. The scope of the present disclosure should not be limited to the above-mentioned 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 from it. Depending on the terminology and technology applied, a 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 known as a gNB), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a repeater, a low-power node such as a femto, a pico, etc.

[0038] The term "terminal device" refers to any terminal device capable of wireless communication. As an example and not limitation, the terminal device may also be referred to as a communication device, a user equipment (UE), a user station (SS), a portable user station, a mobile station (MS) or an access terminal (AT). The terminal device may include, but is not limited to, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless regional loop phone, a tablet computer, a wearable terminal device, a personal digital assistant (PDA), a portable computer, a desktop computer, an image capture terminal device (such as a digital camera), a game terminal device, a music storage and playback device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop embedded device (LEE), a laptop device (LME), a USB dongle, a smart device, a wireless customer premises equipment (CPE), an Internet of Things (IoT) device, a watch or other wearable device, a head-mounted display (HMD), a vehicle, a drone, medical equipment and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronic devices, equipment operating on commercial and / or industrial wireless networks, etc. The terminal device may also correspond to the mobile terminal (MT) part of an IAB node (eg, a relay node).In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" may be used interchangeably.

[0039] In Uu positioning, a positioning reference unit (PRU) may be a device or network node with a reliable location (e.g., a roadside unit, RSU for short, another user equipment (UE), etc.), which may be activated according to the needs of a location management function (LMF) to perform specific positioning operations (e.g., measurement and / or transmission of specific positioning signals). For example, the PRU may be a 5G network entity, which may be designated by a 5G NR network to assist in one or more positioning sessions. The following text box describes some non-limiting introductory information of the PRU that may be used in some example embodiments of the present disclosure. However, it should be noted that the example embodiments of the present disclosure are not limited to the current definition or features of the PRU shown in the text box. On the contrary, the example embodiments of the present disclosure may also be applicable to future PRUs or other similar units that may have a different definition or features from the current PRU but have similar functions to the current PRU.

[0040] In Release 17 enhanced positioning, RAN1 considered it necessary and subsequently introduced the concept of Positioning Reference Unit (PRU). The PRU can be an entity designated by the LMF to calculate positioning-related correction and / or assistance data to be allocated to the target UE. The PRU data can be used by the target UE to correct its own position measurement and / or calculate a more accurate position estimate.

[0041] In contrast to an anchor UE, a PRU may neither measure reference signals sent by a target UE nor send reference signals with the intention to be measured by a target UE. Instead, a UE in a PRU state may be used as a reference unit that performs similar measurements as a UE in a target or anchor state, which reference unit may then be used to correct the original positioning of the target UE. In addition, a PRU may serve several target UEs, i.e., a PRU may provide corrections to measurements of one or more SL positioning signals, where such signals may be used by one or more target UEs. In other words, the activity of a PRU may be associated with a SL positioning source and not necessarily with the activity of a single target UE.

[0042] For example, PRU data may include cross-checking whether a given link is LOS, selecting the best TX PRS beam that the target UE should measure, thereby eliminating the need for exhaustive beam scanning of the target UE, etc. PRU data can also be used for infrastructure positioning, where the LMF performs refinement of the position estimate based on PRU data. In infrastructure positioning, the LMF can assign the PRU role to the terminal entity or the network entity and has full control over the following: who can become a PRU based on what criteria and for how long; what correction data the PRU will calculate; how often; how to use this data; which interfaces are used to send corrections to the target UE, etc.

[0043] The LMF can thus activate and deactivate a considerable number of sufficiently accurate PRUs in a given geographical area, such that the NR network achieves the right balance between two aspects. On the one hand, there is the signaling overhead for transmitting correction data between the network, the PRUs and the target UEs. On the other hand, there is the computational power of the PRUs to update the required correction data more or less frequently. However, in SL positioning (e.g. in partial coverage or no coverage), in principle no central entity knows all PRU-capable terminals and target UEs in the geographical area. Therefore, it is important to: (1) design and size the PRU pool of devices, (2) activate and deactivate the PRU functionality of devices, (3) trust the devices, and (4) enable the devices to transfer correction data to the target SL peers, thereby achieving a balance between the above two aspects.

[0044] The example embodiments of the present disclosure cover the above-mentioned gap by proposing a method for solving the PRU management problem (especially in SL positioning), thereby improving the positioning performance of the terminal device in the communication network, for example, by allowing the UE to activate the PRU function without the coordination of a central entity. More specifically, some example embodiments of the present disclosure propose a framework for transferring PRU functions between UEs such as SL UEs. The framework can enable one or more target UEs (such as SL UEs) to complete their ongoing positioning sessions (such as SL positioning sessions) involving PRU interactions. In cases where these sessions require PRU assistance, the framework can also ensure that there are sufficient PRUs for current and planned positioning sessions (such as SL positioning sessions). As a result, the target UE can be enabled to correct its own position measurement and / or calculate a more accurate position estimate. The principles and embodiments of the present invention are described in detail below in conjunction with the accompanying drawings.

[0045] Figure 1A An example of a network environment 100 in which some example embodiments of the present disclosure may be implemented is shown. The network environment 100 may include a terminal device 110, a group 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 group of terminal devices 120 may communicate with the network device 105. In some example embodiments, the network device 105 may be a gNB providing a 3GPP New Radio (NR) cell. In other example embodiments, the network device 105 may be an eNB providing an LTE cell. The air interface over which the terminal device 110, the group of terminal devices 120, and the network device 105 communicate may be compatible with 3GPP technical specifications, such as those defining the fifth generation (5G) NR system standard.

[0046] In the following description, the terminal device 110 may be used as an example terminal device that performs a PRU function at a certain point in time. In other words, the terminal device 110 acts as a PRU at this point in time. In contrast, a group of terminal devices 120 may not perform a PRU function at this point in time. That is, a group of terminal devices 120 is not a PRU at this point in time. As shown in Figure 1, a group of terminal devices 120 includes terminal devices 120-1, terminal devices 120-2, terminal devices 120-3, etc. and terminal devices 120-N. Note that the number N can be any suitable natural number. It should be understood that the number of network devices and terminal devices is for illustrative purposes only and does not imply any limitation. The network environment 100 may include any suitable number of network devices and terminal devices suitable for implementing embodiments of the present disclosure. Note that some example embodiments of the present disclosure can be implemented without the network device 105.

[0047] The terminal device 110 and a group of terminal devices 120 may also communicate directly via a sidelink interface. The sidelink interface may also be referred to as a ProSe interface, a 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 vehicle communication system. In the vehicle communication system, the terminal device 110 and a group of terminal devices 120 may communicate with each other 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. Therefore, although FIG. 1 depicts the terminal device 110 and a group of terminal devices 120 as mobile phones, the terminal device 110 and a group of terminal devices 120 may be any type of user equipment.

[0048] The terminal device 110 and a group of terminal devices 120 can communicate through a side link resource pool. The side link resource pool may include a group of time / frequency resources for side link transmission or reception. The side link resource pool can be used for all unicast, multicast or broadcast communications of a given UE. In the frequency domain, the resource pool may include multiple subchannels, each subchannel including multiple physical resource blocks (PRBs). In various example embodiments, the subchannel may include, for example, 10, 12, 15, 20, 25, 50, 75 or 100 PRBs. In some example embodiments, the PRBs of the subchannels and the subchannels of the resource pool may be continuous.

[0049] In the time domain, the side link resource pool may include multiple time slots, which may be continuous or non-continuous. In some example embodiments, the time slots for the side link resource pool may be configured by a bitmap, for example, sent by the network device 105, to indicate which time slots are part of the side link resource pool. The bitmap may have a period of 10240 milliseconds and a bitmap length between 10 and 160. In some example embodiments, the physical time slots may include all time slots, including non-side link time slots, while the logical time slots may include only time slots in the resource pool. For example, consider the following 10-bit bitmap: [1, 1, 0, 1, 1, 0, 1, 1, 1, 1]. This bitmap indicates that 10 physical time slots include 8 logical time slots of the side link resource pool.

[0050] The resources of the sidelink may be allocated in a variety 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 a group of terminal devices 120. In a second mode (mode 2), the transmitting UE (e.g., the terminal device 110) may sense the channel and select its own resources for transmission. Mode 2 resource allocation may include multiple operations, including, for example: resource pool configuration; sensing; resource selection; and sidelink transmission.

[0051] The resource pool configuration may include the network device 105 providing configuration information to the terminal device 110 and a group of terminal devices 120 via control signaling (e.g., 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 a group of terminal devices 120. After the UE is configured with the resource pool, the sending UE may perform a sensing process. Within the sensing window, the sending UE sends decoded sidelink control information (SCI) to determine data priority indication and resource reservation information. The sending UE may also measure channel quality indicators, such as reference signal received power (RSRP). The sidelink RSRP measurement may be based on a physical sidelink control channel (PSCCH) demodulation reference signal (DMRS) or a physical sidelink shared channel (PSSCH) DMRS.

[0052] Based on the sensing operation, the transmitting UE can select resources from within the resource selection window. Resources can be selected at a subchannel granularity in the frequency domain and a time slot granularity in the time domain. The transmitting UE can identify candidate resources within the resource selection window. If the candidate resources are reserved and their associated RSRP measurements are above a predetermined threshold, the resources of the resource selection window can be excluded from the candidate resources. The transmitting UE can then select resources from the identified candidate resources. In some example embodiments, the selection can be randomized. The transmitting UE can then encode the sidelink data on the selected resources for transmission.

[0053] Communications in the network environment 100 may be implemented according to any suitable communication protocol, including but not limited to cellular communication protocols of the first generation (1G), second generation (2G), third generation (3G), fourth generation (4G) and fifth generation (5G), wireless local area network communication protocols such as Institute of Electrical and Electronics Engineers (IEEE) 802.11, and / or any other protocol currently known or developed in the future. In addition, communications may utilize any appropriate wireless communication technology, including 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 access (OFDM), discrete Fourier transform spread OFDM (DFT-s-OFDM) and / or any other technology currently known or developed in the future.

[0054] Figure 1B and Figure 1C Examples of two side link resource allocation modes, Mode 1 and Mode 2, which can be used in some example embodiments of the present disclosure are shown respectively. In particular, Figure 1B shows mode 1 of side link resource allocation, while Figure 1C Mode 2 of sidelink resource allocation is shown.

[0055] During 3GPP Release 16, NR Sidelink (SL) has been designed to facilitate user equipment (UE) to communicate with other nearby UEs via direct / SL communication. Two resource allocation modes have been specified, and a SL transmitter (Tx) UE can 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, the sidelink transmit resources are allocated to the SL Tx UE by the network (NW), while the SL Tx UE in Mode 2 autonomously selects its SL transmit resources.

[0056] like Figure 1B As shown, in mode 1, the network device (e.g., gNB) 105 may be responsible for SL resource allocation, and the configuration and operation may be similar to the configuration and operation on the Uu interface. The MAC layer details of the process can be found, for example, in section 5.8.3 of 38.321. More specifically, at 102, the terminal device 110 as a SL Tx UE may send a sidelink scheduling request (SL-SR) to the network device 105. At 104, the network device 105 may indicate the resource allocation to the terminal device 110. At 106, the terminal device 110 may send a sidelink transmission (e.g., PSCCH or PSSCH) to the terminal device 120-1. At 108, the terminal device 120-1 may send a sidelink feedback (e.g., PSFCH) to the terminal device 110.

[0057] like Figure 1C As shown, in mode 2, the SL UE can autonomously perform resource selection with the help of a sensing process. More specifically, a SL Tx UE in NR SL mode 2 can first perform a sensing process through a configured SL transmission resource pool in order to obtain knowledge of resources reserved by other nearby SL Tx UEs. Based on the knowledge obtained from the sensing, the SL Tx UE can select resources from the available SL resources accordingly. In order for the SL UE to perform sensing and obtain the necessary information to receive SL transmissions, it may be necessary to decode the side link control information (SCI). In Release 16, the SCI associated with data transmission may include a first stage SCI and a second stage SCI, and their contents are standardized, for example, in 3GPP TS38.212.

[0058] Figures 1D to 1F Three examples of sidelink positioning scenarios in which some example embodiments of the present disclosure may be implemented are shown. In particular, Figure 1D An example of a sidelink absolute use case is shown, Figure 1E shows an example of a sidelink relative use case, and Figure 1FExamples of sidelink assistance use cases are shown. In some examples, these sidelink positioning scenarios can be related to V2X and public safety. In addition, Figure 1D and Figure 1E The use cases in can be either without coverage or with coverage in sidelink-only mode, and the use cases in Figure 1 can be with coverage or with partial coverage.

[0059] In Release 18, positioning, and in particular sidelink positioning, will be an important study item / work item (SI / WI). The agreed way forward for positioning in 3GPP may include extended 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 (roughly in descending order of popularity): ranging, low-power positioning, accuracy enhancement (e.g., down to centimeter level), RAT-dependent positioning integrity, and reduced latency.

[0060] For ranging, the most identified techniques so far are probably 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 is probably the most identified technique here. In general, the main techniques proposed to improve accuracy (besides sidelink assistance) are probably terrestrial carrier phase positioning, PRS / SRS bandwidth aggregation and the use of wide bandwidth at 60GHz, which also implies the ability to transmit PRS in unlicensed spectrum, which is also seen as relevant for sidelink positioning.

[0061] In addition, the proposed objectives may cover positioning based on sidelink and sidelink assistance; 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 60GHz). Support for small data transmission (SDT) triggered by the mobile terminal (MT) may also be provided, for example, at least for network-initiated positioning use cases.

[0062] In some example embodiments of the present disclosure, sidelink positioning can support three key use cases. Figure 1D As shown, one such use case may be referred to as the Sidelink Absolute use case, which is characterized by positioning based on the device (known location) and the absolute location known (e.g., longitude and latitude). Figure 1EAs shown in FIG. 1 , another use case may be referred to as a sidelink relative use case, characterized by the distance and angle calculated by the target and the relative position being known. As shown in FIG. 1 , a further use case may be referred to as a sidelink assisted use case, characterized by the position calculated by the location service (LCS) and the absolute position being known (e.g., longitude and latitude).

[0063] Figure 1G and Figure 1H Two examples of inter-UE coordination scenarios are shown in which some example embodiments of the present disclosure may be implemented. Specifically, Figure 1G An example is shown in which the coordinating UE (UE A) is also the intended recipient of UE B, and Figure 1H An example is shown where the coordinating UE (UE A) is not the intended recipient of UE B.

[0064] In the approved 3GPP Release 17 WI NR_SL_enh, SL resource allocation enhancement for Mode 2 has been identified as one of the objectives, where inter-device coordination will be studied to improve reliability and reduce latency, with the following content:

[0065] exist Figure 1G In one of the inter-UE coordination scenarios depicted in (denoted as inter-UE coordination scheme 1 in 3GPP), UE A (RX-UE) may select a preferred SL transmission resource (e.g., based on its perception) and recommend the selected resource to UE B (TX-UE), where UE B may select its SL transmission resource by considering the resources indicated by UE A and additionally performing its own perception, e.g., UE B may or may not use the recommended resource to transmit to UE A. Thus, by using the inter-UE coordination scheme, UE A may attempt to ensure that there are no packet collisions or strong interference on its selected resources, and thus transmissions from UE B to UE A may occur with high (higher) reliability.

[0066] exist Figure 1H In another inter-UE coordination scenario depicted in (denoted as Inter-UE Coordination Scheme 2 in 3GPP), UE A can monitor transmissions occurring in the SL resource pool, and whenever a collision or half-duplex problem is detected (either in past or future resources), UE A can notify the affected UEs.

[0067] Figure 2 An example of a process flow 200 for a terminal device to hand over a PRU function to another terminal device according to some example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1ADescribe process flow 200. It should be understood that although Figure 1A The process flow 200 is described in the network environment 100 of FIG. 1 , but the process flow can also be applied to other communication scenarios where the PRU function or similar function is handed over from a terminal device to another terminal device.

[0068] In the process flow 200, the terminal device 110 sends (205) a handover request 202 (or simply request 202) to a group of terminal devices 120 (including terminal device 120-1, terminal device 120-2, ... and terminal device 120-N). The handover request 202 can be used for handover of the PRU function of the terminal device 110. In other words, the purpose of the handover request 202 is to handover (or transfer) the PRU function of the terminal device 110 to one or more of the group of terminal devices 120. In general, the handover request 202 can be sent (205) by the terminal device 110 to the group of terminal devices 120 in various transmission modes. For example, the terminal device 110 can send (205) the handover request 202 to the group of terminal devices 120 by broadcasting a sidelink message. As another example, the terminal device 110 can send (205) the handover request 202 to the group of terminal devices 120 by corresponding sidelink messages.

[0069] As reference Figure 1A As mentioned, when the terminal device 110 is a PRU, a group of terminal devices 120 may not be a PRU at that moment. Therefore, before the terminal device 110 sends (205) the handover request 202 to a group of terminal devices 120, the terminal device 110 may need to determine a group of terminal devices 120 from all terminal devices that can communicate with the terminal device 110, for example, through side link communication. The terminal device 110 may determine a group of terminal devices 120 in a variety of ways. For example, the terminal device 110 may simply determine all terminal devices available for side link communication with the terminal device 110 as a group of terminal devices 120. In another example, the terminal device 110 may randomly select some terminal devices that can be used for side link communication with the terminal device 110 as a group of terminal devices 120. As another example, the terminal device 110 may determine a group of terminal devices 120 based on a candidate list that records candidate terminal devices that can be used to provide PRU functionality. Reference will be made below to Figure 3 Example embodiments related to candidate lists are described in further detail.

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

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

[0072] After receiving the handover request 202, a group of terminal devices 120 may send a corresponding group of handover responses 204-1 to 204-N to the terminal device 110 in response to the handover request 202. For example, each handover response may indicate whether the corresponding terminal device accepts the handover request 202. More specifically, the terminal device 120-1 sends (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 manner, the terminal device 120-2 sends (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. In addition, the terminal device 120-N sends (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 group of terminal devices 120 may send a different handover response in different situations. Without loss of generality, the terminal device 120-1 will be used as an example terminal device to describe these different handover responses. Other terminal devices in the group of terminal devices 120 may send corresponding handover responses in a similar manner. Generally speaking, if the terminal device 120-1 is able to provide the PRU function instead of the terminal device 110, the terminal device 120-1 may accept the handover request 202 and send a handover response 204-1 including an acceptance indication. Otherwise, if the terminal device 120-1 is not able to provide the PRU function instead of the terminal device 110, the terminal device 120-1 may reject the handover request 202 and send a handover response 204-1 including a rejection 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 case, if the terminal device 120-1 has the capability to provide a PRU function with the PRU configuration indicated in the handover request 202, the terminal device 120-1 may send a handover response 204-1 including 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 to provide a PRU function with the PRU configuration indicated in the handover request 202, the terminal device 120-1 may send a handover response 204-1, which may include an indication that the terminal device 120-1 rejects 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 also receive another handover request from another terminal device other than the terminal device 110. For ease of description, the other terminal device may be referred to as the terminal device 120-T. In addition, it is assumed that the handover request 202 may be referred to as the 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 may be used to hand over the PRU function of the terminal device 120-T to that of the terminal device 120-1. In addition, 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 case, the terminal device 120-1 may search for a broad PRU configuration that covers both the first PRU configuration and the second PRU configuration. In other words, the terminal device 120-1 may determine the presence or absence of such a broad PRU configuration in which each of the first PRU configuration and the second PRU configuration is part of the broad PRU configuration. If the terminal device 120-1 determines that there is a broad PRU configuration, the terminal device 120-1 may send a handover response 204-1 containing a mapping table. The mapping table (or simply referred to as a table) may map the PRU configuration determined by the terminal device 120-1 to the terminal device (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 may know that the terminal device 120-1 recommends the broad PRU configuration to replace both the first PRU configuration and the second PRU configuration. Otherwise, if the terminal device 120-1 determines that there is no wide PRU configuration, the terminal device 120-1 may send a handover response 204-1 including a compromise PRU configuration that is a compromise between the first PRU configuration and the second PRU configuration. For example, the compromise PRU configuration may mean that the PRU provided by the terminal device 120-1 is shorter than the time period indicated by the PRU configuration (such as the first PRU configuration or the second PRU configuration) in the handover request (such as the first handover request or the second handover request), or a subset of the auxiliary data indicated by the PRU configuration in the handover request is provided, etc.

[0077] Summarizing the above possible contents of the handover responses 204-1 to 204-N, from the perspective of the terminal device 110 as the receiving device of the handover response 204, each of the set of handover responses 204 may contain the following contents. For example, the handover response may simply contain an indication that the handover request is accepted. Conversely, the handover response may alternatively contain an indication that the handover request is rejected. As another example, the handover response may contain a table that maps a PRU configuration determined by the second terminal device to a terminal device that requests the second terminal device to perform a PRU handover. The table may associate the terminal device 110 with a broad PRU configuration. This broad PRU configuration may cover the PRU configuration indicated in the handover request 202. In some other scenarios, the handover response may contain a compromise PRU configuration that is a compromise between the PRU configuration indicated in the handover request 202 and another PRU configuration. Another PRU configuration may be indicated in another handover request (i.e., the second handover request) received by the terminal device 120-1 from another terminal device (i.e., the terminal device 120-T). In this way, the handover response 204 may provide useful information to the terminal device 110, thereby facilitating a possible handover of the PRU function between the terminal device 110 and one or more terminal devices in the group of terminal devices 120.

[0078] Continue to refer Figure 2 , the terminal device 110 receives a corresponding set of handover responses 204-1 to 204-N (collectively referred to as a set of handover responses 204) from a set of terminal devices 120. For example, the terminal device 110 may receive (220-1) a handover response 204-1 from the terminal device 120-1. Similarly, the terminal device 110 may receive (220-2) a handover response 204-2 from the terminal device 120-2. In addition, the terminal device 110 may receive (220-N) a 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 to hand over the PRU function from the terminal device 110 to these destination terminal devices. Therefore, the destination terminal device may refer to the transfer destination of the handover of the PRU function determined (230) by the terminal device 110. In other words, the terminal device 110 may select a destination terminal device to activate its PRU function to replace the terminal device 110. In one example, the terminal device 110 may determine (230) only one terminal device (e.g., the terminal device 120-1) as the destination terminal device for handing over the PRU function. In another example, the terminal device 110 may determine (230) multiple terminal devices as the destination terminal devices for handing over the PRU function, including the terminal device 120-1 and the terminal device 120-N, such as Figure 2 shown.

[0080] The terminal device 110 may determine a destination terminal device in a group of terminal devices 120 in a variety of ways. For example, the terminal device 110 may select all terminal devices that accept the handover request 202 as the destination terminal devices. For another example, the terminal device 110 may randomly select one or more terminal devices from the terminal devices that accept the handover request 202 as the destination terminal devices. As another example, based on a group of handover responses 204, the terminal device 110 may determine either or both of the predicted positioning performance after the handover and the corresponding resource efficiency of a group of terminal devices 120. Then, the terminal device 110 may select one or more destination terminal devices from a group of terminal devices 120 based on either or both of the predicted positioning performance, the resource efficiency, and the positioning performance requirements. In this way, the terminal device 110 may ensure good positioning performance in the network environment 100 after the handover.

[0081] In order to complete the handover of the PRU function from the terminal device 110 to one or more destination terminal devices, the terminal device 110 may send a handover indication to the destination terminal device to complete the handover of the PRU function. For example, when the terminal device 120-1 and the terminal device 120-N are selected as the destination terminal devices by the terminal device 110, the terminal device 110 may send (235) a handover indication 206-1 to initiate the handover of the PRU function, and send (245) a handover indication 206-N to initiate the handover of the PRU function. Note that although Figure 2 The terminal device 110 is depicted as sending handover indications 206-1 and 206-N to the terminal devices 120-1 and 120-N, respectively, but this depiction does not impose any limitation on the scope of the present disclosure. In other example embodiments, the terminal device 110 may send a single message containing the handover indication, for example via a broadcast transmission. In some example embodiments, the terminal device 110 may deactivate the PRU function after sending the handover indications 206-1 and 206-N. Thus, 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 function. In addition, the terminal device 120-N may receive (250) the handover indication 206-N from the terminal device 110 and then initiate the handover of the PRU function.

[0082] Through the process flow 200 of the example embodiments of the present disclosure, the positioning performance of terminal devices in a communication network can be improved, for example, by allowing the UE to activate the PRU function without coordination by a central entity. More specifically, through some example embodiments of the process flow 200, a framework for transferring PRU functions between UEs (such as SL UEs) is proposed. The framework can enable one or more target UEs (such as SL UEs) to complete their ongoing positioning sessions (such as SL positioning sessions) involving PRU interactions. The framework can also ensure that there are sufficient PRUs for current and planned positioning sessions (such as SL positioning sessions) when PRU assistance is required. As a result, the target UE can be enabled to correct its own position measurement and / or calculate a more accurate position estimate.

[0083] In some example embodiments, to complete 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 in place of the terminal device 110. Similarly, 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 in place of the terminal device 110. In this way, the PRU functionality of the terminal device 110 may be replaced by the PRU functionality of the terminal devices 120-1 and 120-N without adversely affecting positioning performance in the network.

[0084] In some cases, there may be some terminal devices in the group of terminal devices 120, which accept the handover request 202 from the terminal device 110 but are not determined as destination terminal devices by the terminal device 110. Therefore, for these terminal devices, the handover of the PRU function is actually canceled. In some example embodiments, these terminal devices may be notified in an explicit manner or an implicit manner to cancel the handover of the PRU function. As an example of an explicit manner and with reference to Figure 2 , assuming that from a group of terminal devices 120 and based on a group of handover responses 204, the terminal device 110 determines the terminal device 120-2 to avoid handing over the PRU function 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 function to the terminal device 120-2. For example, the reason may be that the positioning performance after the PRU function is handed over to the terminal device 120-2 is lower than the case where the PRU function is handed over to the terminal device 120-1 or 120-N.

[0085] In this case, the terminal device 110 may send (255) a handover cancellation indication 208 to cancel the handover to the terminal device 120-2. Upon receiving (260) the handover cancellation indication 208 from the terminal device 110, the terminal device 120-2 may keep the PRU function of the terminal device 120 inactive. In other words, the terminal device 120-2 may not provide a PRU function to replace the PRU function of the terminal device 110. In this explicit manner, the terminal device 120-2 may be notified of the handover cancellation indication 208 as soon as possible, thereby improving the efficiency of the process 200.

[0086] As an example of an implicit manner, when sending (215-2) the handover response 204-2 to the terminal device 110, the terminal device 120-2 may start a timer for the expected PRU function handover. If the timer expires and there is no handover indication from the terminal device 110, the terminal device 120-2 may determine that the handover of the PRU function is canceled, and thus the PRU function of the terminal device 120-2 may be kept inactive. In this implicit manner, the terminal device 110 does not need to send a handover cancellation indication, thereby reducing signaling overhead.

[0087] In some example embodiments, before the terminal device 110 sends (205) the handover request 202 to the group of terminal devices 120, the terminal device 110 may determine whether a handover of the PRU functionality is required. If the terminal device 110 determines that a handover is required, the first terminal device 110 may send (205) the handover request 202 to the group of terminal devices 120. In this way, the terminal device 110 may 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 group of terminal devices 120.

[0088] When determining whether a handover is required, the terminal device 110 may consider various possible factors. For example, a factor to be considered may be the expiration of the PRU activity timer of the first terminal device. In addition, another possible factor to be considered may be that the available power level at the terminal device 110 is below a threshold. As another example, another possible factor is considered to be unable to meet the positioning integrity requirements of the first terminal device. As another example, another possible factor to be considered may be the need of the first terminal device to serve more urgent services. In addition, another possible factor to be considered may be an explicit request for a handover PRU function of another terminal device or a serving network device. In addition, another possible consideration may be that the terminal device is performing a PRU function for a sidelink positioning session, determining that the terminal device has high positioning integrity. In addition, another possible factor to be considered may be that the terminal device has a low level of uncertainty about its own position. In addition, another possible consideration may be that the mobility of the terminal device is similar to that of the first terminal device, and that the handover helps to share load. It should be noted that when determining whether a handover is required, the terminal device 110 may consider any one or more of the above factors. Considering one or more of these factors, the terminal device 110 may make a more reasonable decision on whether a handover is required.

[0089] As described above, in some example embodiments, the terminal device 110 may determine a group of terminal devices 120 based on the candidate list. More specifically, in order to determine a group of terminal devices 120 to which a handover request is to be sent, the terminal device 110 may maintain a candidate list of candidate terminal devices that may be used for the PRU function. In other words, the candidate list indicates the candidate terminal devices determined by the terminal device 110 to be used for the PRU function. In such an example embodiment, the terminal device 110 may select a group of terminal devices 120 from the candidate list, so that the handover request may be more efficient, thereby reducing the signaling overhead of the handover request transmission.

[0090] Figure 3 An example of a process flow 300 for a terminal device to generate and update a candidate list maintained by the terminal device according to some example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1A The process flow 300 is described. It should be understood that although the process flow 300 has been described in the network environment 100 of FIG. 1 , the process flow can also be applied to other communication scenarios of generating and updating a candidate list.

[0091] In process flow 300, the terminal device 110 may generate (305) a candidate list that records candidate terminal devices that can be used for PRU functionality. In some example embodiments, since the candidate list indicates terminal devices that can provide PRU functionality, the terminal device 110 may generate (305) the candidate list based on the detection of terminal devices that can be used for PRU functionality. For example, the candidate list may be populated when the terminal device 110 hears a SL PRU configuration / activation message including a PRU-specific inter-UE coordination (IUC) message. Alternatively or additionally, the candidate list may be populated when the terminal device 110 observes that the UE has completed its positioning and the UE is configured to transition to a PRU state upon completion of its positioning. This is particularly beneficial in certain scenarios where initiating a sidelink positioning session with a specific anchor / PRU UE requires the UE to agree to act as a PRU when the session is completed. Alternatively or additionally, the candidate list may be populated when the terminal device 110 allows or is equipped with PRU configuration, or assists another UE in acting as a PRU for other target UEs. In this way, the candidate list may be generated in an efficient manner.

[0092] Continue to refer Figure 3 If the terminal device 110 determines (310) that the candidate list needs to be updated, the terminal device 110 may perform an update of the candidate list. To perform the update of the candidate list, the terminal device 110 may send (315) an update request 302 to the candidate terminal devices in the candidate list. The update request 302 may be used to update the candidate list maintained by the terminal device 110. It should be noted that the candidate terminal devices in the candidate list are Figure 3 1 and 130 -X, are collectively referred to as candidate terminal devices 130 . Figure 2 The group of terminal devices 120 shown in can be selected from the candidate terminal devices 130 and are therefore part of the candidate terminal devices 130. Therefore, the number X can be a natural number greater than or equal to the number N. Accordingly, in Figure 3 In the embodiment of the present invention, terminal device 110 may send (315) update request 302 to terminal devices 130-1 to 130-X. In some example embodiments, update request 302 may be sent via a single broadcast message. In some other example embodiments, update request 302 may be sent via separate messages for 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. Specifically, the terminal device 130-1 may receive (320-1) the update request 302 from the terminal device 110. Similarly, the terminal device 130-2 may receive (320-2) the update request 302 from the terminal device 110. Furthermore, the terminal device 130-X may receive (320-X) the update request 302 from the terminal device 110.

[0094] The terminal devices 130-1 to 130-X may then send corresponding 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, the duration of their service as a PRU, the time-frequency (time slot, PRB) resources they can measure, etc. Another type of information may be a location estimate and the level of certainty and integrity associated with the location estimate, a location source, such as a global navigation satellite system (GNSS), NR Uu, etc. A third type of information may be a mobility type, such as direction, speed, trajectory, etc. A fourth type of information may be correction data capabilities, such as line-of-sight (LoS) indication or probability, sidelink angle of departure (AoD) uncertainty, etc. A fifth type of information may be from whom and how many other PRU refresh requests have been received in the past T seconds. A sixth type of information may be whether they have been or are currently a PRU, and for which sources they are providing corrections. A seventh type of information may be whether the PRU candidate is associated with a dual PRU that may replace the PRU candidate in the event of a sudden unavailability, e.g., PRUs that have identified themselves as experiencing 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 may send (325-1) the PRU function information 304-1 of the terminal device 130-1 to the terminal device 110. Similarly, the terminal device 130-2 may send (325-2) the PRU function information 304-2 of the terminal device 130-2 to the terminal device 110. Furthermore, the terminal device 130-X may send (325-X) the PRU function 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 may receive the PRU function information of the corresponding candidate terminal device 130. More specifically, the terminal device 110 may receive (330-1) the PRU function information 304-1 of the terminal device 130-1 from the terminal device 130-1. Similarly, the terminal device 110 may receive (330-2) the PRU function information 304-2 of the terminal device 130-2 from the terminal device 130-2. In addition, from the terminal device 130-X, the terminal device 110 may receive (330-X) the PRU function information 304-X of the terminal device 130-X. The terminal device 110 may then update (335) the candidate list based on the PRU function information of the candidate terminal device 130. Through process 300, the terminal device 110 may improve the determination efficiency and accuracy of a group of terminal devices 120, thereby optimizing process 200.

[0097] With the candidate list generated or updated, the terminal device 110 can then select a group of terminal devices 120 from the candidate terminal devices 130 recorded in the candidate list. In this way, the possibility of a group of terminal devices 120 accepting the handover request 202 can be increased, thereby making the process flow 200 more efficient. In general, the terminal device 110 can perform the selection in a variety of ways. For example, the terminal device 110 can select candidate terminal devices with the latest PRU function information as a group of terminal devices 120. As another example, the terminal device 110 can randomly select some candidate terminal devices from the candidate list. In another example, the terminal device 110 can select candidate terminal devices that pass the qualification test as a group of terminal devices 120. The following will refer to Figure 4 Such example embodiments are described in further detail.

[0098] Figure 4 An example of a process flow 400 for a terminal device to notify other terminal devices to perform a qualification test according to some example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1A Describe process flow 400. It should be understood that although Figure 1A The process flow 400 is described in the network environment 100 of FIG. 1 , but the process flow can also be applied to other communication scenarios of notifying and performing qualification testing.

[0099] In process flow 400, terminal device 110 may determine (405) eligibility tests for a subset of candidate terminal devices in the candidate list. Figure 4 The terminal devices 140-1 to 140-M are collectively referred to as a subset of the candidate terminal devices 140. The subset of the terminal devices 140 can be selected from Figure 3The terminal devices 130 in the candidate list are selected and thus become part of the candidate terminal devices 130, so the number M may be a natural number less than or equal to the number X. On the other hand, in some example embodiments, since a group of terminal devices 120 are determined to be part of a subset of terminal devices 140 that pass the qualification test, the number M may be greater than or equal to the number N.

[0100] Continue to refer Figure 4 , the terminal device 110 may send (410) an indication 402 of a qualification test to a subset of the candidate terminal devices 140. On the one hand, the indication 402 may indicate a test item for the qualification test. For example, the test item may include measuring a side link positioning reference signal (SL-PRS) and calculating a subset of correction data, such as a LoS probability. On the other hand, the indication 402 may also be used as a trigger for performing the qualification test. Accordingly, the subset of the candidate terminal devices 140 may receive the indication 402 from the terminal device 110. In particular, the terminal device 140-1 may receive (415-1) an indication 402 from the terminal device 110. Similarly, the terminal device 140-2 may receive (415-2) an indication 402 from the terminal device 110. In addition, the terminal device 140-M may receive (415-M) an indication 402 from the terminal device 110.

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

[0102] Afterwards, the subset of candidate terminal devices 140 may send their corresponding test results to terminal device 110. More specifically, terminal device 140-1 may send (425-1) test result 404-1 to terminal device 110. Similarly, terminal device 140-2 may send (425-2) test result 404-2 to terminal device 110. In addition, terminal device 140-M may transmit (425-M) test result 404-M to terminal device 110.

[0103] Accordingly, the terminal device 110 may receive corresponding test results 404-1 to 404-M (collectively referred to as test results 404) from a subset of the candidate terminal devices 140. More specifically, the terminal device 110 may receive (430-1) the test result 404-1 from the terminal device 140-1. Similarly, the terminal device 110 may receive (430-2) the test result 404-2 from the terminal device 140-1. In addition, the terminal device 110 may receive (430-M) the test result 404-M from the terminal device 140-M. The terminal device 110 may then determine (430) a group of terminal devices 120 based on the test results 404. For example, the terminal device 110 may select a terminal device with a better test result as a group of terminal devices 120. Through the process flow 400, the terminal device 110 may ensure that the selected group of terminal devices 120 is qualified for the handover of the PRU function.

[0104] Figure 5 Another example of a process flow for a terminal device to notify other terminal devices to perform a qualification test according to some example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1A Describe process flow 500. It should be understood that although Figure 1A The process flow 500 is described in the network environment 100 of FIG. 1 , but the process flow can also be applied to other communication scenarios of notifying and performing qualification testing.

[0105] Figure 5 The example embodiments will be depicted and described from the perspective of the current PRU 502 and the candidate PRUs 504. More specifically, 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 may decide the best next PRU or multiple PRUs.

[0106] In process flow 500, current PRU 502 may create (505) a qualification test that may include a sidelink positioning reference signal (SL-PRS) configuration and a subset of correction data for a plurality of tests, such as test 1 through test X. In some example embodiments, current PRU 502 may evaluate a list of candidate PRUs and select a subset of them for performing the PRU qualification test.

[0107] Next, the current PRU 502 may transfer (510) the qualification test to the selected candidate PRU. For example, the current PRU sends a "PRU qualification test" configuration to the selected PRU or UE. The test configuration message may contain a subset of the SL-PRS to be measured and the correction data to be calculated, such as the LoS probability.

[0108] The selected candidate PRU may then perform qualification tests as indicated and respond with test results including the requested correction data. For example, candidate PRU 504 may perform (515) qualification tests, which may include measuring the SL-PRS and calculating the required correction data. For example, the test results reported by candidate PRU 504 may include correction data 1 for test 1, correction data 2 for test 2, and correction data X for test X.

[0109] The current PRU 502 may then evaluate (525) the test results reported by the candidate PRU 504. Specifically, the current PRU 502 evaluates the correction data, and if the reported correction data matches its own correction data within a certain margin, the candidate PRU may be considered to be PRU qualified. For example, in the case where the correction data is a LoS probability, the current PRU 502 may check whether the difference between the candidate LoS and the current LoS is less than a threshold, such as 0.1. If the judgment result is positive, the current PRU 502 may conclude that the candidate PRU 504 observes the same channel as the SL-PRS source, and therefore the PRU 504 is qualified.

[0110] Figure 6 An example of a process flow 600 for a terminal device to send an active PRU list to other terminal devices to update a candidate list maintained by the terminal device according to some example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1A Describe process flow 600. It should be understood that although Figure 1A The process flow 600 is described in the network environment 100 of FIG. 1 , but the process flow can also be applied to other communication scenarios in which a terminal device sends an active PRU list to other terminal devices to update a candidate list maintained by the terminal device.

[0111] In process flow 600, if the terminal device 110 completes (605) the handover of the PRU function 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 that provide the PRU function through the handover of the PRU function. In other words, the active PRU list 602 may record the new terminal devices known to the terminal device 110 as active PRUs after the handover of the PRU function. The terminal device 110 may then send (615) the active PRU list 602 to the candidate terminal device 130 to update the corresponding candidate list maintained by the candidate terminal device 130. Note that in Figure 6In the example embodiment of FIG. 6 , the active PRU list 602 is sent to all candidate terminal devices 130 in the candidate list, regardless of whether the candidate terminal device is selected by the terminal device 110 as one of the group of terminal devices 120 .

[0112] Accordingly, the candidate terminal device 130 may receive an active PRU list 602 from the terminal device 110. Specifically, the terminal device 130-1 may receive (620-1) an active PRU list 602 from the terminal device 110. Similarly, the terminal device 130-2 may receive (620-2) an active PRU list 602 from the terminal device 110. In addition, the terminal device 130-X may receive (620-X) an active PRU list 602 from the terminal device 110.

[0113] After receiving the active PRU list 602 from the terminal device 110, the candidate terminal devices 130 can update their candidate lists respectively, because the active PRU list 602 can indicate the new terminal devices known to the terminal device 110 as active PRUs after the PRU function handover. More specifically, the terminal device 130-1 can update (625-1) the candidate list maintained by the terminal device 130-1 based on the active PRU list 202. The candidate list indicates the candidate terminal devices determined by the terminal device 130-1 to be available for the PRU function. Similarly, the terminal device 130-2 can update (625-2) the candidate list maintained by the terminal device 130-2 based on the active PRU list 202. The candidate list indicates the candidate terminal devices determined by the terminal device 130-2 to be available for the PRU function. More specifically, the terminal device 130-X can update (625-X) the candidate list maintained by the terminal device 130-X based on the active PRU list 202. The candidate list indicates terminal devices determined by the terminal device 130 -X to be candidates for use in the PRU function.

[0114] Figure 7 Another example of a process flow 700 for a terminal device to hand over a PRU function to another terminal device according to some example embodiments of the present disclosure is shown. For the purpose of discussion, reference will be made to Figure 1A Describe process flow 700. It should be understood that although Figure 1A The process flow 700 is described in the network environment 100 of FIG. 1 , but the process flow can also be applied to other communication scenarios where a PRU function or a similar function is handed over from a terminal device to another terminal device.

[0115] In some example embodiments, Figure 7The current PRU 703 in may be the terminal device 110 in FIG. 1 , the candidate PRU-1 707 may be the terminal device 120-1 in FIG. 1 , the candidate PRU-2 709 may be the terminal device 120-2 in FIG. 1 , the candidate PRU-3 711 may be the terminal device 120-3 in FIG. 1 , and the target UE 701 may be the terminal device 120-N in FIG. 1 . In some other example embodiments, the target UE 701 may be any one of the terminal devices shown or not shown in FIG. 1 , the current PRU 703 may be any one of the terminal devices shown or not shown in FIG. 1 , the candidate PRU-1 707 may be any one of the terminal devices shown or not shown in FIG. 1 , the candidate PRU-2 709 may be any one of the terminal devices shown or not shown in FIG. 1 , and the candidate PRU-3 711 may be any one of the terminal devices shown or not shown in FIG. 1 .

[0116] Generally speaking, Figure 7 The example embodiments in the present invention may propose a SL positioning framework for PRU function transfer and retuning. Specifically, the example embodiments describe how a sidelink UE (referred to as UE for short) that wants or needs to give up its PRU function, hereinafter referred to as the current PRU, can transfer the PRU function to at least one of multiple other UEs, referred to as multiple candidate PRUs.

[0117] It is important to note that a candidate PRU can be a SL UE with any of the following. (1) The SL UE implicitly agrees to assume the role of a PRU as a result of triggering its own positioning session (e.g., sidelink, Uu, or non-NR based session). In other words, a SL UE that becomes the target of a SL positioning session will transition to the PRU state after its positioning is completed. (2) The SL UE explicitly agrees, for example, upon a PRU request from a target UE, another PRU, a serving gNB, etc., to assume the role of a PRU for a period of time under explicitly indicated configurations and conditions (i.e., conditions agreed upon by the candidate PRU and the requesting node), such as: the type of correction data it can calculate; the time-frequency resources (time slots, PRBs) it can monitor; and the duration of PRU availability. (3) The SL UE explicitly indicates that it is available to be a PRU, for example, via SL broadcast.

[0118] In process flow 700, current PRU 703 sends (705) PRU correction data 702 to target UE 701. Therefore, target UE 701 receives (710) PRU correction data from current PRU 703 for positioning target UE 701. Next, 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 (i.e., UEs that are available for the PRU role but are not selected to assume this role).

[0119] In some examples, the list may be populated whenever the current PRU hears a SL PRU configuration / activation message including a PRU-specific inter-UE coordination (IUC) message. The list may be populated whenever the current PRU observes that the UE has completed its positioning and when the UE is configured to transition to the PRU state when its positioning is completed. This is particularly beneficial in certain scenarios where initiating a sidelink positioning session with a specific anchor / PRU UE requires the UE to agree to act as a PRU when the session is completed. This list may be populated whenever the current PRU grants or configures the PRU to configure / assist another UE to act as a PRU for other target UEs.

[0120] Then, the current PRU 703 performs (720) candidate PRU update evaluation. For example, the current PRU 703 evaluates whether it needs to refresh its own candidate PRU list, and in the case of a positive conclusion (e.g., too old entry), it generates a refresh request for the candidate PRU. Thereafter, the current PRU 703 sends (725) the candidate PRU refresh request 704 to the candidate PRUs. Thereafter, 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.

[0121] This transmission may be achieved by broadcasting a SL message that requests all nearby UEs (candidate PRUs 707, 709, 711, etc.) to indicate one or more of the following information: (1) PRU willingness, e.g., the duration they may serve as a PRU, the time-frequency (time slot, PRB) resources they may measure, etc.; (2) location estimate and the associated certainty and integrity level of the location estimate, location source, e.g., Global Navigation Satellite System (GNSS), NR Uu, etc.; (3) mobility type (e.g., direction, speed, trajectory, etc.); (4) correction data capability, e.g., LoS indication or probability, SL-AoD uncertainty, etc.; (5) from whom and how many other PRU refresh requests have been received in the past T seconds; (6) whether they have been or are currently a PRU, and for which sources they are providing corrections; and (7) whether the PRU candidate is associated with a dual PRU that may replace the PRU candidate in the event of sudden unavailability, e.g., PRUs that have identified themselves to experience similar mobility and radio conditions, such as devices moving together in a UE group, such as in a train.

[0122] Then, the candidate PRU-1 707 transmits (735-1) the candidate PRU refresh response 706-1 to the current PRU 703. The candidate PRU-2 709 transmits (735-2) the candidate PRU refresh response 706-2 to the current PRU 703. The candidate PRU-3 711 transmits (735-3) the candidate PRU refresh response 706-3 to the current PRU 703. Therefore, 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.

[0123] Specifically, each candidate PRU may reply with the above list, and the current PRU updates (refreshes) its candidate UE list. It should be noted that the candidate PRU may refresh its own location information before sending the above list. Examples include using mobility information to correct its most recent position fix, requiring assistance from the serving gNB, for example, generating a positioning request, and obtaining its non-NR position such as GNSS if available.

[0124] The current PRU 703 then triggers (745) a PRU handover. For example, after completing the list refresh, the current PRU evaluates whether a PRU functional transfer is required. This may be triggered based on the following factors: (1) a set of conditions that the current PRU UE has met, e.g., the PRU activity timer has expired or the available power level has dropped below a critical threshold (power saving constraint); (2) its location integrity requirement can no longer be ensured, e.g., the PRU detects severe interference or the PRU detects a high level of uncertainty in its own location estimate; (3) the current PRU UE needs to serve a service of higher urgency; (4) an explicit request from another UE or serving gNB to hand over the PRU role; (5) the candidate PRU is already acting as a PRU for other sidelink positioning sessions and therefore may have the ability to multiplex its correction data transmission for resource efficiency; (6) the candidate PRU is observed to have high positioning integrity and / or low level of uncertainty in its own location; and (7) the candidate PRU is observed to have similar mobility to the current PRU and the current PRU decides to perform a temporary handover such as load sharing.

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

[0126] In an alternative embodiment, the assessment of PRU eligibility may involve a qualification test triggered by the current PRU for the selected subset of candidates. For example, it may request the candidate to calculate correction data for one or more active SL-PRS resources and report this correction data. If the candidate correction matches the current PRU's own correction data, a handover is triggered.

[0127] In some example embodiments, the handover request may further include the following: (1) if the candidate PRU accepts the request, the candidate PRU shall use the (multiple) PRU configuration, and the configuration may also include the minimum duration that the candidate UE is required to serve as the PRU; (2) conditions for accepting the handover request, for example, when performing an indicated PRU handover eligibility test, the correction data must be within a certain indicated range, where the PRU handover test may involve a simple PRU correction calculation.

[0128] Each candidate PRU may evaluate the PRU request. In some example embodiments, the candidate may receive multiple PRU configuration requests from different PRU handover requesters. In this case, the candidate may evaluate whether the multiple requests can be resolved with a single PRU configuration, or whether they conflict. In the case where the multiple requests can be resolved with a single PRU configuration, the candidate may assign the requester (current PRU) ID to the PRU configuration. In the event of a conflict, the candidate may resolve the conflict, for example, by selecting a compromise configuration. After resolution, the candidate may reply with an ACK / NACK and / or reply with a compromise PRU configuration and / or a mapping table associating the requester ID with the PRU configuration.

[0129] Therefore, the candidate PRU-1 707 sends (760-1) PRU Handover Accept 712-1 to the current PRU 703. The candidate PRU-2 709 sends (760-2) PRU Handover Accept 712-2 to the current PRU 703. The candidate PRU-3 711 does not send a handover response. Therefore, the current PRU 703 receives (765-1) PRU Handover Accept 712-1 from the candidate PRU-1 707. The current PRU 703 receives (765-2) PRU Handover Accept 712-2 from the candidate PRU-1 711.

[0130] Thereafter, the current PRU 703 performs (770) a PRU handover response evaluation. Specifically, the current PRU 703 may evaluate all responses and select and activate one or more UEs to hand over the PRU role to them. The selection may be done based on a) positioning performance and b) resource efficiency. Positioning performance relates to the accuracy achieved after the PRU handover. Therefore, the selection may be done by comparing the PRU uncertainty level of each option as well as the mobility type and correction data capability. Resource efficiency relates to the amount of resources consumed by the PRU usage. Therefore, a candidate PRU that serves multiple target UEs using the same resources is preferable to a PRU that serves only one target UE, so that in the former case the overall resource efficiency is higher. The selection process may take into account positioning requirements in terms of performance, so that the selected candidate is one that meets the requirements and achieves the most efficient resource usage.

[0131] Then, the current PRU 703 sends (775) a PRU handover indication 714 to the candidate PRU-1 707. Therefore, the candidate PRU-1 707 receives (780) the PRU handover indication 714 from the current PRU 703. Then, the candidate PRU-1 707 sends (795) the 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 the target UE 701.

[0132] It should be noted that a candidate PRU that has responded to the PRU request but has not been selected for handover may be indicated with a PRU handover cancel message that a PRU handover is not expected. For example, the current PRU 703 sends (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) a PRU handover cancel 716 from the current PRU 703, and the candidate PRU-3 711 receives (790-3) a PRU handover cancel 716 from the current PRU 703. Alternatively, the candidate PRU may be configured (e.g., in the PRU handover request) with a timer within which a PRU handover from the current PRU to the candidate PRU is expected. Upon expiration of the timer, the candidate PRU 703 may consider itself outside the current PRU handover.

[0133] In an alternative embodiment, the current PRU 703 may create a new list of active PRUs and indicate the active PRU list to all candidate PRUs (both selected and unselected). The benefit of this approach is that unselected candidates can refresh their own candidate lists.

[0134] In summary, the proposed framework provided by process flow 700 defines the following new functions and signals as part of the SL positioning framework. The current PRU can maintain a list of candidate PRUs, which can be refreshed based on the following: (1) detection of ongoing nearby PRU (re)selection, where the configuration is implemented on the SL; (2) testing of available candidate UEs to determine their PRU eligibility; in other words, the current PRU initiates the eligibility test that the candidate needs to perform, and only after receiving the test results from the candidate and evaluating the results, the current PRU initiates PRU transfer; and (3) pre-agreement with other UEs to transfer the PRU role; this refers to the situation where the SL UE has implicitly or explicitly indicated its availability for performing PRU functions.

[0135] In addition, the current PRU can evaluate the need for PRU functionality transfer and trigger the transfer by performing an SL exchange with a set of candidate PRUs available on the list. The SL exchange can be aimed at establishing and pre-agreed on the minimum PRU functionality that each candidate can ensure. In other words, if the candidate does not support the current PRU configuration, the PRU functionality can be modified by the candidate and approved by the current PRU.

[0136] In addition, based on the pre-agreed result, the current PRU can select and activate the best UE from the responding candidates and complete the PRU function transfer. Subsequently, it can release the waiting candidates from the PRU transfer.

[0137] The proposed framework enables one or more target UEs to complete their ongoing SL positioning sessions involving PRU interactions without any interruption in obtaining PRU assistance (e.g., position correction data). This is achieved by ensuring that sufficient PRUs are present for current and planned SL positioning sessions in case these sessions require PRU assistance. As a result, the target UE is enabled to correct its own position measurements, and / or calculate a more accurate and / or faster position estimate.

[0138] 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 be for: a) the same SL-PRS resource but different correction data is required, possibly with different refresh rates; and b) different SL-PRS resources. The candidate PRU can evaluate the different correction data required on each SL-PRS resource and whether they can generate each data at the required refresh rate. The candidate PRU can then generate a compromise correction capability for each SL-PRS resource. An example is shown in the table below.

[0139] Note that Correction_data(prs_idx, type_idx) may represent correction data, which is the correction data requested for the SL-PRS indexed by prs_idx and the type indicated by type_idx. Also note that in the above table, the correction list for each SL-PRS resource may not contain all required corrections, contain all required corrections, or contain some of the required corrections.

[0140] Figure 8 A flowchart 800 of a method implemented at a first terminal device according to some example embodiments of the present disclosure is shown. For discussion purposes, the method 800 will be described from the perspective of the terminal device 110 with reference to FIG.

[0141] At box 810, the first terminal device 110 sends a request to a group of terminal devices, requesting a handover of the PRU function of the first terminal device. At box 820, the first terminal device 110 receives a corresponding set of handover responses from the group of terminal devices. At box 830, the first terminal device 110 determines a second terminal device from the group of terminal devices based on the set of handover responses, and the second terminal device is used to handover the PRU function from the first terminal device to the second terminal device 120-1. Step 840, the first terminal device 110 sends a handover indication to initiate the handover to the second terminal device 120-1.

[0142] In some example embodiments, the method 800 further comprises: selecting a group of terminal devices from a candidate list of candidate terminal devices, the candidate terminal devices being available for the PRU function.

[0143] In some example embodiments, selecting a group of terminal devices includes: determining a qualification test for a subset of candidate terminal devices in a candidate list; sending an indication of the qualification test to the subset of candidate terminal devices; receiving corresponding test results from the subset of candidate terminal devices; and determining a group of terminal devices based on the test results.

[0144] In some example embodiments, the method 800 further includes: generating a candidate list based on detecting a terminal device that can be used for the PRU function; and in response to determining that the candidate list needs to be updated, performing an update of the candidate list.

[0145] In some example embodiments, performing an update of the candidate list includes: sending an update request to the candidate terminal devices in the candidate list; receiving PRU function information of the corresponding candidate terminal devices from the candidate terminal devices; and updating the candidate list based on the PRU function information.

[0146] In some example embodiments, determining the second terminal device includes: determining at least one of a predicted positioning performance after handover and corresponding resource efficiency of a group of terminal devices based on a group of handover responses; and selecting the second terminal device from a group of terminal devices based on at least one of the predicted positioning performance, resource efficiency and positioning performance requirements.

[0147] In some example embodiments, method 800 further includes: determining a third terminal device from a group of terminal devices based on a group of handover responses, the third terminal device being used to avoid handing over the PRU function from the first terminal device to the third terminal device; and sending a handover cancellation indication to the third terminal device to cancel the handover.

[0148] In some example embodiments, the method 800 further comprises: determining whether a handover of the PRU functionality is required; and in response to determining that a handover is required, sending a request for a handover to a group of terminal devices.

[0149] In some example embodiments, the first terminal device determines that handover is required based on at least one of the following: expiration of a PRU activity timer for the first terminal device; an available power level at the first terminal device being below a threshold; a failure to meet a positioning integrity requirement for the first terminal device; a need for the first terminal device to serve more urgent services; an explicit request from another terminal device or a serving network device to handover a PRU function; a determination that the terminal device is performing a PRU function for a sidelink positioning session; a determination that the terminal device has high positioning integrity; a determination that the terminal device has a low level of uncertainty about its own location; and a determination that the mobility of the terminal device is similar to that of the first terminal device and that handover helps with load sharing.

[0150] In some example embodiments, the request for handover comprises at least one of: an ordered list of a set of terminal devices; a set of PRU configurations to be used by the terminal devices; conditions for accepting the request for handover.

[0151] In some example embodiments, each handover response in a set of handover responses includes one of: an indication that the request for handover is accepted; an indication that the request for handover is rejected; a table that maps a PRU configuration determined by the second terminal device to a terminal device that requests the second terminal device to perform a PRU handover, the table associating the first terminal device with a broad PRU configuration, the broad PRU configuration covering the PRU configuration indicated in the request for handover; a compromise PRU configuration between the PRU configuration indicated in the request for handover and another PRU configuration, the compromise PRU configuration being indicated in another request for handover received by the second terminal device from a third terminal device.

[0152] In some example embodiments, method 800 further includes: in response to completion of the handover, determining an active PRU list indicating a terminal device providing the PRU functionality through the handover; and sending the active PRU list to the candidate terminal device for updating a corresponding candidate list maintained by the candidate terminal device.

[0153] In some example embodiments, the first terminal device and the group of terminal devices communicate via sidelink communications.

[0154] Fig. 9 A flowchart 900 of a method implemented at a second terminal device according to some other embodiments of the present invention is shown. For discussion purposes, the method 900 will be described from the perspective of the terminal device 120-1 with reference to FIG.

[0155] At block 910 , the second terminal device 120 - 1 receives a first request from the first terminal device 110 , the first request being for handover of a PRU function of the first terminal device 110 ; and sends a handover response to the first request to the first terminal device 110 .

[0156] In some example embodiments, sending a handover response includes: if the second terminal device has the ability to provide a PRU function with the first PRU configuration indicated in the first request, sending a handover response, the handover response including an indication that the second terminal device accepts the request; otherwise, sending a handover response, the handover response including an indication that the second terminal device rejects the request.

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

[0158] In some example embodiments, sending a handover response includes: in response to determining that the broad PRU configuration exists, sending a handover response including a table, the table mapping the PRU configuration determined by the second terminal device to the terminal device requesting the second terminal device to perform a PRU handover, the table associating the first terminal device and the third terminal device with the broad PRU configuration; and in response to determining that the broad PRU configuration does not exist, sending a handover response including a compromise PRU configuration, the compromise PRU configuration being between the first PRU configuration and the second PRU configuration.

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

[0160] In some exemplary embodiments, method 900 also includes: receiving an update request from the first terminal device, the update request is for an update of a candidate list maintained by the first terminal device, the candidate list indicating candidate terminal devices that can be used for the PRU function; and sending PRU function information of the second terminal device to the first terminal device.

[0161] In some example embodiments, the method 900 further includes: in response to receiving a handover indication for initiating the handover from the first terminal device, activating a PRU function of the second terminal device.

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

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

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

[0165] In some example embodiments, method 900 further includes: receiving an active PRU list from the first terminal device indicating terminal devices that provide the PRU function through 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 that can be used for the PRU function.

[0166] In some example embodiments, the first terminal device and the second terminal device communicate via sidelink communication.

[0167] In some example embodiments, an apparatus capable of executing method 800 (e.g., terminal device 110) may include components for executing corresponding steps of method 800. The apparatus may be implemented in any suitable form. For example, the apparatus may be implemented in a circuit or a software module.

[0168] In some example embodiments, the apparatus includes: a component for sending a request to a group of terminal devices, requesting a handover of a PRU function for a first terminal device; a component for receiving a corresponding set of handover responses from the group of terminal devices; a component for determining a second terminal device from the group of terminal devices based on the set of handover responses, the second terminal device being used to handover the PRU function from the first terminal device to the second terminal device; and a component for sending a handover indication to initiate the handover to the second terminal device.

[0169] In some example embodiments, the apparatus further comprises: means for selecting a group of terminal devices from a candidate list of candidate terminal devices, the candidate terminal devices being available for the PRU function.

[0170] In some example embodiments, a component for selecting a group of terminal devices includes: a component for determining a qualification test for a subset of candidate terminal devices in a candidate list; a component for sending an indication of the qualification test to the subset of candidate terminal devices; a component for receiving corresponding test results from the subset of candidate terminal devices; and a component for determining a group of terminal devices based on the test results.

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

[0172] In some example embodiments, the component for performing an update of the candidate list includes: a component for sending an update request to the candidate terminal devices in the candidate list; a component for receiving PRU function information of the corresponding candidate terminal devices from the candidate terminal devices; and a component for updating the candidate list based on the PRU function information.

[0173] In some example embodiments, the component for determining the second terminal device includes: a component for determining at least one of the predicted positioning performance after handover and the corresponding resource efficiency of a group of terminal devices based on a set of handover responses; and a component for selecting the second terminal device from a group of terminal devices based on at least one of the predicted positioning performance, resource efficiency and positioning performance requirements.

[0174] In some example embodiments, the apparatus further includes: a component for determining a third terminal device from a group of terminal devices based on a group of handover responses, the third terminal device being used to avoid handing over the PRU function from the first terminal device to the third terminal device; and a component for sending a handover cancellation indication to the third terminal device to cancel the handover.

[0175] In some example embodiments, the apparatus further comprises: means for determining whether a handover of the PRU functionality is required; and means for sending a request for handover to a group of terminal devices in response to determining that a handover is required.

[0176] In some example embodiments, the first terminal device determines that handover is required based on at least one of the following: expiration of a PRU activity timer for the first terminal device; an available power level at the first terminal device being below a threshold; a failure to meet a positioning integrity requirement for the first terminal device; a need for the first terminal device to serve more urgent services; an explicit request from another terminal device or a serving network device to handover a PRU function; a determination that the terminal device is performing a PRU function for a sidelink positioning session; a determination that the terminal device has high positioning integrity; a determination that the terminal device has a low level of uncertainty about its own location; and a determination that the mobility of the terminal device is similar to that of the first terminal device and that handover helps with load sharing.

[0177] In some example embodiments, the request for handover comprises at least one of: an ordered list of a set of terminal devices; a set of PRU configurations to be used by the terminal devices; conditions for accepting the request for handover.

[0178] In some example embodiments, each handover response in a set of handover responses includes one of: an indication that the request for handover is accepted; an indication that the request for handover is rejected; a table that maps a PRU configuration determined by the second terminal device to a terminal device that requests the second terminal device to perform a PRU handover, the table associating the first terminal device with a broad PRU configuration, the broad PRU configuration covering the PRU configuration indicated in the request for handover; a compromise PRU configuration between the PRU configuration indicated in the request for handover and another PRU configuration, the compromise PRU configuration being indicated in another request for handover received by the second terminal device from a third terminal device.

[0179] In some example embodiments, the apparatus further comprises: a component for determining, in response to completion of the handover, an active PRU list indicating a terminal device that provides the PRU functionality through the handover; and a component for sending the active PRU list to a candidate terminal device for updating a corresponding candidate list maintained by the candidate terminal device.

[0180] In some example embodiments, the first terminal device and the group of terminal devices communicate via sidelink communications.

[0181] In some example embodiments, the apparatus further comprises means for performing other steps in some example embodiments of method 800. In some example embodiments, the apparatus comprises at least one processor; and at least one memory comprising computer program code, the at least one memory and the computer program code being configured to cause performance of the apparatus using the at least one processor.

[0182] In some example embodiments, an apparatus capable of executing method 900 (eg, terminal device 120-1) may include components for executing corresponding steps of method 900. The apparatus may be implemented in any suitable form. For example, the apparatus may be implemented in a circuit or a software module.

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

[0184] In some example embodiments, the component for sending a handover response includes: a component for sending a handover response if the second terminal device has the ability to provide a PRU function with the first PRU configuration indicated in the first request, the handover response including an indication that the second terminal device accepts the request; otherwise, a component for sending a handover response, the handover response including an indication that the second terminal device rejects the request.

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

[0186] In some example embodiments, the component for sending a handover response includes: a component for sending a handover response including a table in response to determining that a broad PRU configuration exists, the table mapping a PRU configuration determined by the second terminal device to a terminal device requesting the second terminal device to perform a PRU handover, the table associating a first terminal device and a third terminal device with the broad PRU configuration; and a component for sending a handover response including a compromise PRU configuration in response to determining that the broad PRU configuration does not exist, the compromise PRU configuration being between the first PRU configuration and the second PRU configuration.

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

[0188] In some example embodiments, the apparatus further comprises: a component for receiving an update request from the first terminal device, the update request being for an update of a candidate list maintained by the first terminal device, the candidate list indicating candidate terminal devices that can be used for the PRU function; and a component for sending PRU function information of the second terminal device to the first terminal device.

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

[0190] In some example embodiments, the apparatus further comprises means for maintaining a PRU function of the second terminal device inactive in response to receiving a handover cancellation indication from the first terminal device to cancel the handover.

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

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

[0193] In some example embodiments, the apparatus further comprises: a component for receiving, from the first terminal device, an active PRU list indicating terminal devices that provide the PRU function through handover; and a component for updating, based on the active PRU list, a candidate list maintained by the second terminal device, the candidate list indicating candidate terminal devices that can be used for the PRU function.

[0194] In some example embodiments, the first terminal device and the second terminal device communicate via sidelink communication.

[0195] In some example embodiments, the apparatus further comprises means for performing other steps in some example embodiments of method 900. In some example embodiments, the apparatus comprises at least one processor; and at least one memory comprising computer program code, the at least one memory and the computer program code being configured to cause performance of the apparatus with the at least one processor.

[0196] Fig.10 A simplified block diagram of a device 1000 suitable for implementing some example embodiments of the present disclosure is shown. The device 1000 may be used to implement a communication device, such as the terminal device 110, the terminal device 120, or the network device 105 shown in FIG. 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.

[0197] The communication module 1040 is used for two-way communication. The communication module 1040 has at least one antenna to facilitate communication. The communication interface may represent any interface necessary to communicate with other network elements.

[0198] As non-limiting examples, processor 1010 may be of any type suitable for a local technology network, and may include one or more of the following: a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 1000 may have multiple processors, such as application specific integrated circuit chips, which are time-slaved to a clock that synchronizes a master processor.

[0199] The memory 1020 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 1024, electrically programmable read-only memory (EPROM), flash memory, hard disk, compact disk (CD), digital video disk (DVD), and other magnetic storage and / or optical storage. Examples of volatile memories include, but are not limited to, random access memory (RAM) 1022 and other volatile memories that do not persist during a power outage.

[0200] Computer program 1030 includes computer executable instructions executed by associated processor 1010. Program 1030 may be stored in ROM 1024. Processor 1010 may perform any suitable actions and processes by loading program 1030 into RAM 1022.

[0201] The embodiments of the present disclosure can be implemented by means of the program 1030, so that the device 1000 can execute the following steps: Figures 2 to 7 Any process of the present disclosure discussed. The embodiments of the present invention can also be implemented by hardware or a combination of software and hardware.

[0202] In some example embodiments, the program 1030 may be tangibly embodied in a computer-readable medium, which may be included in the device 1000 (such as in the memory 1020) or other storage device 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 type of tangible non-volatile storage device, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

[0203] Fig.11 1 shows a block diagram of an example of a computer readable medium 1100 according to some example embodiments of the present disclosure. The computer readable medium 1100 has a program 1030 stored thereon. Note that although Fig.11 Computer readable medium 1100 is depicted in the form of a CD or DVD, but computer readable medium 1100 may be in any other form suitable for carrying or maintaining program 1030.

[0204] Generally, various embodiments of the present disclosure may be implemented in hardware or dedicated circuits, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software that may be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure are shown and described as block diagrams, flow charts, or using some other graphical representations, it should be understood that the blocks, devices, systems, techniques, or methods described herein may be implemented in hardware, software, firmware, dedicated circuits or logic, general hardware or controllers or other computing devices, or some combination thereof in non-limiting examples.

[0205] 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 included in a program module, executed in a device on a target real or virtual processor to perform the above referenced Figure 8Or those instructions of method 800 or 900 described in 9. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The functions of program modules can be combined or split between program modules as needed in various embodiments. Machine executable instructions for program modules can be executed in local or distributed devices. In distributed devices, program modules can be located in local and remote storage media.

[0206] The program code for executing the method of the present disclosure can be written in any combination of one or more programming languages. These program codes can be provided to a processor or controller of a general-purpose computer, a special-purpose computer or other programmable data processing device so that the program code, when executed by the processor or controller, enables the functions / operations specified in the flow chart and / or block diagram to be realized. The program code can be executed entirely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine or entirely on a remote machine or server.

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

[0208] The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, device or apparatus, or any suitable combination of the foregoing. More specific examples of computer readable storage media would include an electrical connection with one or more wires, a portable computer disk, 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 disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0209] In addition, although the operations are depicted in a particular order, this should not be understood as requiring such operations to be performed in the particular order shown or in a sequential order, or performing all the operations shown to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these details should not be interpreted as limitations on the scope of the present disclosure, but should be interpreted as descriptions of features that may be specific to a particular embodiment. Certain features described in the context of a separate embodiment may also be implemented in combination in a single embodiment. On the contrary, the various features described in the context of a single embodiment may also be implemented in multiple embodiments individually or in any suitable sub-combination.

[0210] Although the disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the 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

1. A first terminal device, comprising: at least one processor; as well as at least one memory storing computer program code; The at least one memory and the computer program code are configured to, together with the at least one processor, cause the first terminal device to: Sending a request to a group of terminal devices, the request being for handover of a positioning reference unit (PRU) function of the first terminal device; receiving a corresponding set of handover responses from the set of terminal devices; Based on the set of handover responses, determining a second terminal device from the set of terminal devices, the second terminal device being used to hand over the PRU function from the first terminal device to the second terminal device; as well as A handover indication is sent to the second terminal device to initiate the handover.

2. The first terminal device according to claim 1, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the first terminal device to: The group of terminal devices is selected from a candidate list of candidate terminal devices, and the candidate terminal devices can be used for the PRU function.

3. The first terminal device according to claim 2, wherein the first terminal device selects the group of terminal devices in the following manner: determining eligibility tests for a subset of candidate terminal devices in the candidate list; sending an indication of the eligibility test to the subset of candidate terminal devices; receiving corresponding test results from the subset of candidate terminal devices; as well as The group of terminal devices is determined based on the test results.

4. The first terminal device according to claim 2, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the first terminal device to: generating the candidate list based on detection of terminal devices that can be used for the PRU function; and In response to determining that the candidate list needs to be updated, updating of the candidate list is performed.

5. The first terminal device according to claim 4, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the first terminal device to perform the updating of the candidate list in the following manner: Sending an update request to the candidate terminal device in the candidate list; Receiving PRU function information of the corresponding candidate terminal device from the candidate terminal device; as well as The candidate list is updated based on the PRU function information.

6. The first terminal device according to claim 1, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the first terminal device to determine the second terminal device in the following manner: determining, based on the set of handover responses, at least one of the predicted positioning performance after the handover and corresponding resource efficiencies of the set of terminal devices; and The second terminal device is selected from the group of terminal devices based on at least one of the predicted positioning performance, the resource efficiency and the positioning performance requirement.

7. The first terminal device according to claim 1, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the first terminal device to: Based on the set of handover responses, determining a third terminal device from the set of terminal devices, the third terminal device being configured to avoid handing over the PRU function from the first terminal device to the third terminal device; and A handover cancellation indication is sent to the third terminal device to cancel the handover.

8. The first terminal device according to claim 1, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the first terminal device to: determining whether the handover of the PRU function is required; and In response to determining that the handover is required, the request for the handover is sent to the group of terminal devices.

9. The first terminal device according to claim 8, wherein the first terminal device determines that the handover is required based on at least one of the following: The PRU activity timer of the first terminal device expires; The available power level at the first terminal device is lower than a threshold; Failure to meet the positioning integrity requirements of the first terminal device; The need of the first terminal device to serve a more urgent business; An explicit request from another terminal device or serving network device to hand over the PRU functionality; Determining that the terminal device is performing a PRU function for a sidelink positioning session; Determine that the terminal device has high positioning integrity; Determining that the end device has a low level of uncertainty about its own location; and It is determined that the mobility of the terminal device is similar to that of the first terminal device and that the handover is helpful for load sharing.

10. The first terminal device according to 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; A condition for accepting the request for the handover.

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

12. The first terminal device according to claim 2, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, cause the first terminal device to: In response to the handover being completed, determining an active PRU list indicating a terminal device providing the PRU functionality through the handover; and The active PRU list is sent to the candidate terminal device for updating a corresponding candidate list maintained by the candidate terminal device.

13. The first terminal device according to claim 1, wherein the first terminal device and the group of terminal devices communicate via side link communication.

14. A second terminal device, comprising: at least one processor; as well as at least one memory storing computer program code; The at least one memory and the computer program code are configured to, together with the at least one processor, enable the second terminal device to: receiving a first request from a first terminal device, the first request being for a handover of a positioning reference unit (PRU) function of the first terminal device; as well as A handover response to the first request is sent to the first terminal device.

15. The second terminal device according to claim 14, wherein the second terminal device sends the handover response in the following manner: If the second terminal device has the capability to provide the PRU function with the first PRU configuration indicated in the first request, sending the handover response, the handover response including an indication that the second terminal device accepts the request; otherwise, The handover response is sent, the handover response including an indication that the second terminal device rejects the request.

16. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: receiving a second request from a third terminal device, the second request being for handover of the PRU function of the third terminal device; and It is determined whether a broad PRU configuration covering a first PRU configuration indicated in the first request and a second PRU configuration indicated in the second request exists or does not exist.

17. The second terminal device according to claim 16, wherein the second terminal device sends the handover response in the following manner: in response to determining that the wide PRU configuration exists, sending the handover response including a table, the table mapping the PRU configuration determined by the second terminal device to a terminal device requesting the second terminal device to perform a PRU handover, the table associating the first terminal device and the third terminal device with the wide PRU configuration; and In response to determining that the wide PRU configuration does not exist, sending the handover response including a compromise PRU configuration, the compromise PRU configuration being between the first PRU configuration and the second PRU configuration.

18. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: receiving an indication of a conformity test from the first terminal device; performing the qualification test to obtain a test result; as well as Send the test result to the first terminal device.

19. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: receiving an update request from the first terminal device, the update request being for an update of a candidate list maintained by the first terminal device, the candidate list indicating candidate terminal devices available for the PRU function; and Send PRU function information of the second terminal device to the first terminal device.

20. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: In response to receiving a handover indication for initiating the handover from the first terminal device, activating the PRU function of the second terminal device.

21. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: In response to receiving a handover cancel indication to cancel the handover from the first terminal device, keeping the PRU function of the second terminal device inactive.

22. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: In response to sending the handover response to the first terminal device, starting a timer for anticipating the handover; and In response to expiration of the timer, maintaining the PRU function of the second terminal device inactive.

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

24. The second terminal device according to claim 14, wherein the at least one memory and the computer program code are further configured to, together with the at least one processor, enable the second terminal device to: receiving from the first terminal device an active PRU list indicating a terminal device providing the PRU functionality through the handover; and A candidate list maintained by the second terminal device is updated based on the active PRU list, the candidate list indicating candidate terminal devices available for the PRU function.

25. The second terminal device of claim 14, wherein the first terminal device and the second terminal device communicate via side link communication.

26. A method comprising: sending, at a first terminal device, a request to a group of terminal devices, the request being for handover of a positioning reference unit (PRU) function of the first terminal device; receiving a corresponding set of handover responses from the set of terminal devices; Based on the set of handover responses, determining a second terminal device from the set of terminal devices, the second terminal device being used to hand over the PRU function from the first terminal device to the second terminal device; as well as A handover indication is sent to the second terminal device to initiate the handover.

27. A method comprising: receiving, at a second terminal device, a first request from a first terminal device, the first request being for a handover of a positioning reference unit (PRU) function of the first terminal device; as well as A handover response to the first request is sent to the first terminal device.

28. An apparatus comprising: means for sending, at a first terminal device, a request to a group of terminal devices, the request being for handover of a Positioning Reference Unit (PRU) functionality of the first terminal device; means for receiving a corresponding set of handover responses from the set of terminal devices; for determining, from the group of terminal devices, a component of a second terminal device based on the group of handover responses, the second terminal device being used to hand over the PRU function from the first terminal device to the second terminal device; as well as A component configured to send a handover indication to the second terminal device to initiate the handover.

29. An apparatus comprising: means for receiving, at the second terminal device, from the first terminal device, a first request for handover of a Positioning Reference Unit (PRU) functionality of the first terminal device; as well as Means for sending a handover response to the first request to the first terminal device.

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

Images