Method and apparatus for sidelink positioning

Abstract

The embodiment of the invention relates to a method and equipment for sidelink (SL) positioning. In accordance with an embodiment of the present disclosure, a first user equipment (UE) may include: a transceiver; and a processor coupled to the transceiver and configured to: establish an SL Positioning Protocol (SLPP) session with a plurality of second UEs; and multicast, with the transceiver, an SLPP message in the SLPP session to the plurality of second UEs.

Description

Technical Field

[0001] Embodiments of the present application relate generally to wireless communication techniques, and more particularly to methods and apparatus for sidelink (SL) positioning. Background Art

[0002] Sidelink is a Long Term Evolution (LTE) feature introduced in 3rd Generation Partnership Project (3GPP) Release 12, enabling direct communication between nearby user equipment (UEs) without requiring data to pass through a base station (BS) or core network. Sidelink communication systems have been introduced into 3GPP 5G wireless communication technology, where a direct link between two UEs is referred to as a sidelink.

[0003] SL positioning refers to transmitting a Positioning Reference Signal (PRS) via SL, which can operate independently of network or Radio Access Technology (RAT) coverage and provides a new positioning method to accommodate new network use cases. Currently, further discussion is needed on the details of group SL positioning. Summary of the Invention

[0004] The embodiments of the present application at least provide a technical solution for SL positioning.

[0005] According to some embodiments of the present application, a first UE may include: a transceiver; and a processor, which is coupled to the transceiver and configured to: establish a SL Positioning Protocol (SLPP) session with multiple second UEs; and use the transceiver to multicast SLPP messages in the SLPP session to the multiple second UEs.

[0006] In some embodiments of the present application, the SLPP message includes an indicator indicating a request for confirmation of the SLPP message and a sequence number of the SLPP message.

[0007] In some embodiments of the present application, the processor is further configured to: in response to receiving an SLPP confirmation including the sequence number of the SLPP message from each of one or more second UEs among the multiple second UEs, multicast the next SLPP message in the SLPP session to the multiple second UEs using the transceiver, wherein the one or more second UEs include all of the multiple second UEs or all second UEs among the multiple second UEs within the minimum communication range of the multicast service.

[0008] In some embodiments of the present application, the processor is further configured to perform: step (1): determining whether an SLPP confirmation including the serial number of the SLPP message has not been received from at least one second UE among the one or more second UEs before a certain time period has passed since the last transmission of the SLPP message; and step (2): in response to determining that an SLPP confirmation including the serial number of the SLPP message has not been received from at least one second UE among the one or more second UEs before the time period has passed since the last transmission of the SLPP message, retransmitting the SLPP message to the multiple second UEs using the transceiver.

[0009] In some embodiments of the present application, the processor is further configured to: repeatedly perform steps (1) and (2) until an SLPP confirmation including the sequence number of the SLPP message is received from each of the one or more second UEs, or the maximum number of retransmissions of the SLPP message is reached.

[0010] In some embodiments of the present application, in response to reaching the maximum number of retransmissions of the SLPP message, the processor is further configured to: terminate the SLPP session and multicast an indication of the termination of the SLPP session to the multiple second UEs using the transceiver; abandon the second UE among the one or more second UEs from which the SLPP confirmation including the sequence number of the SLPP message has not been received; retransmit the SLPP message to the second UE from which the SLPP confirmation including the sequence number of the SLPP message has not been received via an existing unicast connection; or trigger establishment of a unicast connection with the second UE from which the SLPP confirmation including the sequence number of the SLPP message has not been received for retransmitting the SLPP message to the second UE.

[0011] In some embodiments of the present application, the processor is further configured to: receive an indication indicating an error of the SLPP message from a second UE among the multiple second UEs using the transceiver; and in response to receiving the indication: terminate the SLPP session and multicast an indication indicating that the SLPP session is terminated to the multiple second UEs using the transceiver; determine that the SLPP transaction associated with the SLPP message has failed, and multicast an identity (ID) of the failed SLPP transaction to the multiple second UEs using the transceiver; or abandon the second UE and continue the SLPP session of other second UEs among the multiple second UEs.

[0012] In some embodiments of the present application, the processor is further configured to determine that the broadcast type for the SLPP message is groupcast based on at least one of: the type of the SLPP message; the group layer 2 ID of the positioning group associated with the SLPP session maintained by the first UE; the broadcast layer 2 ID associated with a location service, the location service being associated with the SLPP session maintained by the first UE; the number of second UEs to which the SLPP message is to be transmitted is greater than 1; the absence of a unicast connection between the first UE and the second UE to which the SLPP message is to be transmitted; or the type of the first UE.

[0013] According to some embodiments of the present application, a second UE may include: a transceiver; and a processor, which is coupled to the transceiver and configured to: establish an SLPP session with a first UE and one or more other second UEs; and receive, with the transceiver, an SLPP message in the SLPP session multicast from the first UE.

[0014] In some embodiments of the present application, the SLPP message includes an indicator indicating a request for confirmation of the SLPP message and a sequence number of the SLPP message.

[0015] In some embodiments of the present application, the processor is further configured to, in response to receiving the SLPP message and successfully decoding the indicator and the sequence number, transmit, with the transceiver, an SLPP acknowledgement including the sequence number of the SLPP message.

[0016] In some embodiments of the present application, if the second UE fails to decode at least one of the indicator or the sequence number, the processor is further configured to: receive the SLPP message retransmitted from the first UE via an existing unicast connection; or establish a unicast connection with the first UE and receive the SLPP message retransmitted from the first UE via the unicast connection.

[0017] In some embodiments of the present application, the processor is further configured to: in response to detecting an error in the SLPP message, transmit, using the transceiver, an indication indicating the error in the SLPP message to the first UE.

[0018] In some embodiments of the present application, the processor is further configured to: in response to receiving an indication multicast from the first UE indicating that the SLPP session is terminated, discard the SLPP message stored for the SLPP session and stop the ongoing SLPP transaction of the SLPP session; or in response to receiving an ID of a failed SLPP transaction multicast from the first UE, discard the SLPP message stored for the failed SLPP transaction.

[0019] According to some embodiments of the present application, a method performed by a first UE may include: establishing an SLPP session with multiple second UEs; and multicasting an SLPP message in the SLPP session to the multiple second UEs.

[0020] According to some embodiments of the present application, a method performed by a second UE may include: establishing an SLPP session with a first UE and one or more other second UEs; and receiving an SLPP message in the SLPP session multicast from the first UE. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to describe the manner in which the advantages and features of the present application can be obtained, the description of the present application is presented by reference to specific embodiments of the present application illustrated in the accompanying drawings. These drawings depict only example embodiments of the present application and therefore should not be considered as limiting its scope.

[0022] Figure 1 is a schematic diagram illustrating an exemplary wireless communication system according to some embodiments of the present application;

[0023] Figure 2 Describe an exemplary SLPP confirmation procedure according to some embodiments of the present application;

[0024] Figure 3 Describe an exemplary SLPP retransmission procedure according to some embodiments of the present application;

[0025] Figure 4 Describe an exemplary SLPP error handling procedure according to some embodiments of the present application; and

[0026] Figure 5 A simplified block diagram illustrating an exemplary apparatus for SL positioning according to some embodiments of the present application. DETAILED DESCRIPTION

[0027] The detailed description of the accompanying drawings is intended as a description of the presently preferred embodiments of the present application and is not intended to represent the only form in which the present application can be practiced. It should be understood that the same or equivalent functions can be accomplished by different embodiments that are intended to be encompassed within the spirit and scope of the present application.

[0028] Although operations are depicted in a particular order in the figures, those skilled in the art will readily recognize that such operations need not be performed in the particular order shown or in sequential order, or that one or more operations may sometimes be skipped among all the illustrated operations to be performed in order to achieve a desired result. Furthermore, the figures may schematically depict one or more example processes in the form of flow charts. However, other operations not depicted may be incorporated into the schematically illustrated example processes. For example, one or more additional operations may be performed before, after, concurrently with, or between any of the illustrated operations. In certain circumstances, multitasking and parallel processing may be advantageous.

[0029] Reference will now be made in detail to some embodiments of the present application, examples of which are illustrated in the accompanying drawings. To facilitate understanding, embodiments are provided in the context of specific network architectures and new service scenarios, such as 3GPP LTE, Advanced LTE, 5G (i.e., New Radio (NR)), Advanced 5G, 6G, etc. It will be apparent to those skilled in the art that, as network architectures and new service scenarios evolve, the embodiments of the present application are also applicable to similar technical problems. Furthermore, the terms used in the present application may be changed without affecting the principles of the present application.

[0030] Figure 1 is a schematic diagram illustrating an exemplary wireless communication system 100 according to some embodiments of the present application.

[0031] like Figure 1 , the wireless communication system 100 includes at least one BS 101 and at least one UE (e.g., UE 102a, UE 102b, UE 102c, and UE 102d). Figure 1 One BS and four UEs are depicted in FIG. 1 , but it is contemplated that any number of BSs and UEs may be included in the wireless communication system 100 .

[0032] The wireless communication system 100 is compatible with any type of network capable of sending and receiving wireless communication signals. For example, the wireless communication system 100 is compatible with wireless communication networks, cellular telephone networks, time division multiple access (TDMA)-based networks, code division multiple access (CDMA)-based networks, orthogonal frequency division multiple access (OFDMA)-based networks, LTE networks, 3GPP-based networks, 3GPP 5G networks, satellite communication networks, high altitude platform networks, and / or other communication networks.

[0033] BS 101 may also be referred to as an access point, an access terminal, a base station, a macrocell, a Node-B, an enhanced or evolved Node-B (eNB), a generalized Node-B (gNB), a home Node-B, a relay node or device, or described using other terms used in the art. BS 101 is typically part of a radio access network that may include a controller communicatively coupled to BS 101.

[0034] According to some embodiments of the present application, UE 102a, UE 102b, UE 102c, and UE 102d may include vehicle UE (VUE), roadside unit (RSU), vulnerable road user (VRU), public safety UE (PS-UE), and / or commercial sidelink UE (CS-UE). In embodiments of the present application, VRU may include pedestrian UE (P-UE), cyclist UE, wheelchair UE, or other UE.

[0035] According to some other embodiments of the present application, UE 102a, UE 102b, UE 102c and UE 102d may include computing devices, such as desktop computers, laptop computers, personal digital assistants (PDAs), tablet computers, smart TVs (e.g., TVs connected to the Internet), set-top boxes, game consoles, security systems (including security cameras), in-vehicle computers, network devices (e.g., routers, switches, and modems), etc.

[0036] According to some other embodiments of the present application, UE 102a, UE 102b, UE 102c and UE 102d may include portable wireless communication devices, smart phones, cellular phones, flip phones, devices with subscriber identity modules, personal computers, selective call receivers, or any other devices capable of sending and receiving communication signals on a wireless network.

[0037] According to some other embodiments of the present application, UE 102a, UE 102b, UE 102c, and UE 102d may include wearable devices, such as smart watches, fitness bands, optical head-mounted displays, etc.

[0038] Furthermore, a UE may be referred to as a subscriber unit, a mobile, a mobile station, a user, a terminal, a mobile terminal, a wireless terminal, a fixed terminal, a subscriber station, a user terminal or device, or described using other terminology used in the art.

[0039] Figure 1 UE 102a and UE 102b in the example shown in FIG are both within the coverage area of BS 101 and can transmit information or data to BS 101 and receive control information or data from BS 101, for example, via an LTE or NR Uu interface.

[0040] UE 102c and UE 102d are outside the coverage area of BS 101. UE 102a may communicate with UE 102b and UE 102c via the SL (e.g., via the PC5 interface as defined in 3GPP standard documents), and UE 102d may communicate with UE 102b and UE 102c via the SL.

[0041] Regarding the sidelink positioning procedure between UEs, SLPP is introduced to support at least the following functionalities: SL positioning capability transfer, SL positioning assistance data exchange, SL location information transfer, error handling, suspension, etc.

[0042] SLPP signaling transmission types include unicast, multicast, and broadcast. Unicast / one-to-one operation can be assumed as the baseline for exchanging SLPP signaling between UEs. SL positioning supports both unicast SLPP session-based operation and "centralized" operation. For example, "centralized" operation may refer to an operation in which a UE performs distance and / or position calculations based on measurement / location information related to itself and / or other UEs.

[0043] For SLPP, there may be a use case with one target UE and one or more anchor UEs. The target UE may be a UE that needs to calculate or know its position (position or location). The anchor UE may be a UE that participates in SL positioning and helps the target UE obtain its position, for example, by sending / receiving SL-PRS and performing related measurements. In addition, there may be a use case with multiple target UEs. For the use case with multiple target UEs, both session-based SLPP procedures and sessionless SLPP procedures are possible. In the session-based SLPP procedure, one or more target UEs and one or more anchor UEs are in the same SLPP session (or in the same group). There may be one location request, and the SLPP message in the SLPP session is associated with the location request, and multiple target UEs in the SLPP session can calculate their positions. Both use cases (i.e., the use case with one target UE and the use case with multiple target UEs) can support session-based SLPP message transport. In addition, both use cases can include one-to-many operations, i.e., the SLPP message is transmitted by one UE and received by multiple UEs. Similar to traditional LPP procedures, session-based SLPP message delivery can support reliable delivery of SLPP messages. However, how to support reliable delivery of SLPP messages for one-to-many use cases in group SL positioning has not been discussed.

[0044] Specifically, reliable delivery of SLPP messages for one-to-many use cases in group SL positioning may involve the following issues.

[0045] Problem #1: How to support reliable delivery of SLPP messages when there are multiple receiving UEs receiving SLPP messages?

[0046] For example, conventional LTE Positioning Protocol (LPP) procedures support reliable delivery of LPP messages through LPP acknowledgments. That is, after transmitting an LPP message, the transmitter (or transmitting UE) may not transmit the next LPP message, but instead wait for an LPP acknowledgment (ACK) from a peer endpoint (e.g., a receiver or receiving UE that received the LPP message). After the transmitter receives the LPP ACK for the LPP message from the peer endpoint, it may transmit the next LPP message. However, with SLPP, if SLPP ACK is supported, multiple endpoints may be able to provide ACKs. Next, we need to discuss how the transmitter handles multiple ACKs.

[0047] As another example, conventional LPP procedures can also support reliable LPP message delivery through LPP message retransmission. That is, after transmitting an LPP message, if the transmitter (or transmitting UE) is unable to receive an LPP ACK for the LPP message from a peer endpoint (e.g., a receiver or receiving UE receiving the LPP message) for a period of time, the transmitter may retransmit the LPP message. The transmitter may repeat this action until the maximum number of retransmissions is reached or the transmitter receives an LPP ACK for the LPP message from the peer endpoint. However, with SLPP, as described above, there may be multiple endpoints that can feedback ACKs, and therefore there may be multiple possible situations, such as the transmitter not receiving an ACK, the transmitter receiving ACKs from some endpoints, or the transmitter receiving ACKs from all endpoints. Next, if SLPP message retransmission is supported, it is necessary to discuss how to perform retransmission in various situations.

[0048] Question #2: What is the UE behavior when an error occurs during SLPP messaging.

[0049] For example, in conventional LPP procedures, after an endpoint performs error detection and discovers an error in a received LPP message, it can respond to the transmitter (or transmitting UE) that transmitted the LPP message with an error indication containing the error cause. Error causes in conventional LPP procedures may include "undefined," "lppMessageHeaderError," "lppMessageBodyError," "epduError," "incorrectDataValue," "lppSegmentationError," and the like, as specified in 3GPP standard documents. However, with SLPP, multiple endpoints may receive SLPP messages. If some endpoints detect errors in a received SLPP message and respond to the transmitter (or transmitting UE) that transmitted the SLPP message with an error indication, how the transmitter handles the error indication needs to be discussed.

[0050] Question 3: How to determine the broadcast type of SLPP message.

[0051] For example, in traditional NR SL, the broadcast type is determined in the vehicle-to-everything (V2X) layer and can be based on the SL service type. For example, some SL service types are always broadcast, while others are always multicast. However, in SL positioning, the broadcast type used for SLPP messages can be determined not only based on location services but also related to other information. Next, we need to discuss how to determine the broadcast type for SLPP messages.

[0052] Embodiments of the present application provide a method for SL positioning, which provides various technical solutions for SLPP ACK, SLPP retransmission, UE behavior when an SLPP message error occurs, and determining the broadcast type for SLPP messages. Embodiments of the present application can at least address the aforementioned issues. Further details of the embodiments of the present application are described below in conjunction with the accompanying drawings.

[0053] According to some embodiments of the present application, an SLPP session may be established between one or more target UEs and one or more anchor UEs. In other words, these UEs form a group and are associated with the same SLPP session. The SLPP session may be associated with a location request with a QoS requirement for location services. The purpose of the location request is to calculate the location (or ranging) of each of the one or more target UEs. The following embodiments may provide several procedures within an SLPP session.

[0054] Figure 2 An exemplary SLPP confirmation procedure according to some embodiments of the present application is described.

[0055] Figure 2 The method in the example may be performed by a first UE (e.g., UE#1) and multiple second UEs (e.g., UE#2-1 and UE#2-2). The first UE may refer to a transmitter (or transmitting UE) that transmits the SLPP message. Each second UE may refer to a receiver (or receiving UE) that receives the SLPP message. In some examples, the first UE may refer to an anchor UE, and each second UE may refer to a target UE. In some other examples, the first UE may refer to a target UE, and each second UE may refer to an anchor UE. In some embodiments of the present application, each of the first UE and multiple second UEs may also be referred to as an endpoint. Although for illustration purposes Figure 2 The two second UEs are depicted in Figure 2The procedure described in the embodiment may involve any number of second UEs. Although the method is described at the system level using three UEs, those skilled in the art will appreciate that the operations implemented in the first UE and the operations implemented in the two second UEs may be implemented separately and combined by other devices having similar functions.

[0056] exist Figure 2 Before the steps shown in FIG. 1 , a first UE (e.g., UE#1) and a plurality of second UEs (e.g., UE#2-1 and UE#2-2) may establish an SLPP session between them. That is, the first UE may establish an SLPP session with the plurality of second UEs, or any second UE in the plurality of second UEs may establish an SLPP session with the first UE and other second UEs in the plurality of second UEs. In other words, when an SLPP session has been established between the first UE and the plurality of second UEs, Figure 2 That is, the first UE and the plurality of second UEs are in a group and in an established SLPP session.

[0057] In step 201, a first UE (e.g., UE#1) may multicast an SLPP message in an SLPP session to multiple second UEs (e.g., UE#2-1 and UE#2-2). The SLPP message may include an indicator requesting an acknowledgment of the SLPP message and a sequence number of the SLPP message. For example, the indicator may be an information element (IE) set to "true," such as "ackRequested."

[0058] Thus, in step 201, each second UE (e.g., UE #2-1 and UE #2-2) may receive a SLPP message multicast from the first UE. In response to receiving the SLPP message, each second UE may decode the indicator and sequence number included in the SLPP message. If the second UE successfully decodes the indicator and sequence number (regardless of whether the message body of the SLPP message can be correctly decoded), in step 202, the second UE may transmit a SLPP acknowledgment including the sequence number of the SLPP message to the first UE. For example, the SLPP acknowledgment may include an IE, such as "ackIndicator," set to the sequence number of the SLPP message.

[0059] exist Figure 2 In the example of FIG, it is assumed that both UE#2-1 and UE#2-2 successfully decode the indicator and sequence number included in the SLPP message received from UE#1. Then, in step 202-a, UE#2-1 may transmit an SLPP acknowledgment including the sequence number of the SLPP message to UE#1; and in step 202-b, UE#2-2 may transmit an SLPP acknowledgment including the sequence number of the SLPP message to UE#1.

[0060] In response to receiving an SLPP confirmation including a sequence number of the SLPP message from each of one or more second UEs (referred to as a group of specific second UEs) among the plurality of second UEs, in step 203, the first UE may multicast the next SLPP message in the SLPP session to the plurality of second UEs.

[0061] In some embodiments of the present application, the group of specific second UEs may include all multiple second UEs. Figure 2 , the multiple second UEs to which UE#1 transmits an SLPP message consist of UE#2-1 and UE#2-2, and UE#1 can multicast the next SLPP message in the SLPP session to UE#2-1 and UE#2-2 in response to receiving an SLPP confirmation including the sequence number of the SLPP message from each of UE#2-1 and UE#2-2.

[0062] In some embodiments of the present application, the group of specific second UEs may include all second UEs in the plurality of second UEs that are within the minimum communication range of the multicast service. That is, if a second UE in the plurality of second UEs is outside the minimum communication range of the multicast service (this may be indicated from a lower layer (e.g., a physical layer or a media access control (MAC) layer)), then the SLPP confirmation from this UE is not counted by the first UE. For example, Figure 2 , the plurality of second UEs to which UE#1 transmits an SLPP message consists of UE#2-1 and UE#2-2. If UE#2-2 is outside the minimum communication range of the multicast service, the specific group of second UEs consists of UE#2-1. Subsequently, UE#1, in response to receiving an SLPP acknowledgment from UE#2-1 including the sequence number of the SLPP message, may multicast the next SLPP message in the SLPP session to UE#2-1 and UE#2-2, regardless of whether UE#1 receives an SLPP acknowledgment from UE#2-2.

[0063] Figure 3 An exemplary SLPP retransmission procedure according to some embodiments of the present application is described.

[0064] Figure 3 The method in the example may be performed by a first UE (e.g., UE#1) and multiple second UEs (e.g., UE#2-1 and UE#2-2). The first UE may refer to a transmitter (or transmitting UE) that transmits the SLPP message. Each second UE may refer to a receiver (or receiving UE) that receives the SLPP message. In some examples, the first UE may refer to an anchor UE, and each second UE may refer to a target UE. In some other examples, the first UE may refer to a target UE, and each second UE may refer to an anchor UE. In some embodiments of the present application, each of the first UE and one or more second UEs may also be referred to as an endpoint. Although for illustration purposes Figure 3 The two second UEs are depicted in Figure 3 The procedure described in the embodiment may involve any number of second UEs. Although the method is described at the system level using three UEs, those skilled in the art will appreciate that the operations implemented in the first UE and the operations implemented in the two second UEs may be implemented separately and combined by other devices having similar functions.

[0065] exist Figure 3 Before the steps shown in FIG. 1 , a first UE (e.g., UE#1) and a plurality of second UEs (e.g., UE#2-1 and UE#2-2) may establish an SLPP session between them. That is, the first UE may establish an SLPP session with the plurality of second UEs, or any second UE in the plurality of second UEs may establish an SLPP session with the first UE and other second UEs in the plurality of second UEs. In other words, when an SLPP session has been established between the first UE and the plurality of second UEs, Figure 3 That is, the first UE and the plurality of second UEs are in a group and in an established SLPP session.

[0066] In step 301, a first UE (e.g., UE#1) may multicast an SLPP message in an SLPP session to multiple second UEs (e.g., UE#2-1 and UE#2-2). The SLPP message may include an indicator requesting an acknowledgment of the SLPP message and a sequence number of the SLPP message. For example, the indicator may be an information element (IE) set to "true," such as "ackRequested."

[0067] Thus, in step 301, each second UE (e.g., UE#2-1 and UE#2-2) may receive the SLPP message multicast from the first UE. In response to receiving the SLPP message, each second UE may decode the indicator and sequence number included in the SLPP message. If the second UE successfully decodes the indicator and sequence number (regardless of whether the message body of the SLPP message can be correctly decoded), in step 302, the second UE may transmit a SLPP acknowledgment including the sequence number of the SLPP message to the first UE. For example, the SLPP acknowledgment may include an IE, such as "ackIndicator," set to the sequence number of the SLPP message. Otherwise, if the second UE cannot successfully decode the indicator and sequence number (e.g., the second UE fails to decode at least one of the indicator or the sequence number), the second UE may not transmit the SLPP acknowledgment to the first UE.

[0068] exist Figure 3In the example of FIG, UE#2-1 successfully decodes the indicator and sequence number included in the SLPP message received from UE#1, while UE#2-2 does not successfully decode the indicator and sequence number included in the SLPP message received from UE#1. Then, in step 302, UE#2-1 may transmit an SLPP acknowledgment to UE#1. UE#2-2 may not transmit an SLPP acknowledgment to UE#1.

[0069] In step 303, the first UE may determine whether a SLPP acknowledgment including a sequence number of the SLPP message has not been received from at least one second UE of one or more second UEs (referred to as a group of specific second UEs) before a certain period of time has passed since the last transmission (e.g., transmission or retransmission) of the SLPP message. That is, the first UE may determine whether SLPP acknowledgments have been received from all second UEs in the group of specific second UEs before the period of time has passed since the last transmission of the SLPP message. The group of specific second UEs may have the same Figure 2 The definitions provided in the described embodiments are the same. For example, the group of specific second UEs may include all of the plurality of second UEs, or include all of the second UEs within the minimum communication range of the multicast service among the plurality of second UEs.

[0070] In step 304, in response to determining that an SLPP acknowledgment including a sequence number of the SLPP message has not been received from at least one second UE in the group of specific second UEs before the time period has elapsed since the last transmission of the SLPP message, the first UE may retransmit the SLPP message to the plurality of second UEs. The retransmitted SLPP message may also include an indicator requesting an acknowledgment of the SLPP message and the sequence number of the SLPP message.

[0071] exist Figure 3 In the example of FIG, it is assumed that the specific second UE group consists of UE#2-1 and UE#2-2. Since only the SLPP acknowledgment including the sequence number of the SLPP message is received from UE#2-1 in step 302, UE#1 can retransmit the SLPP message to UE#2-1 and UE#2-2 in step 304.

[0072] After receiving the retransmitted SLPP message, each second UE may decode the indicator and sequence number included in the retransmitted SLPP message. If the second UE successfully decodes the indicator and sequence number (regardless of whether the message body of the retransmitted SLPP message can be correctly decoded and whether the message is considered a duplicate), in step 305, the second UE may transmit an SLPP acknowledgment including the sequence number of the SLPP message to the first UE. Otherwise, if the second UE cannot successfully decode the indicator and sequence number, the second UE may not transmit an SLPP acknowledgment to the first UE.

[0073] exist Figure 3 In the example of , both UE#2-1 and UE#2-2 successfully decode the indicator and sequence number included in the retransmitted SLPP message. Then, in step 305-a, UE#2-1 may transmit an SLPP acknowledgment including the sequence number of the SLPP message to UE#1. In step 305-b, UE#2-2 may transmit an SLPP acknowledgment including the sequence number of the SLPP message to UE#1. In some other cases, if a second UE (e.g., UE#2-1) has previously correctly received the same SLPP message from UE#1 or has already transmitted an SLPP acknowledgment for the same SLPP message to UE#1, the second UE may not transmit an SLPP acknowledgment for the retransmitted SLPP message to UE#1.

[0074] The first UE may repeatedly perform step 303 and step 304 until a SLPP confirmation including a sequence number of the SLPP message is received from each of the group of specific second UEs, or a maximum number of retransmissions of the SLPP message is reached.

[0075] In case a SLPP acknowledgement including a sequence number of the SLPP message is received from each of the group of specific second UEs, the first UE may multicast the next SLPP message in the SLPP session to the plurality of second UEs at step 306. Figure 3 In the example, since SLPP confirmations including the sequence numbers of SLPP messages are received from both UE#2-1 and UE#2-2, in step 306, UE#1 can multicast the next SLPP message in the SLPP session to UE#2-1 and UE#2-2.

[0076] When the maximum number of retransmissions of the SLPP message is reached, in step 306, the first UE may perform one of the following operations:

[0077] The first UE may terminate the SLPP session and multicast an indication indicating that the SLPP session has been terminated to multiple second UEs (e.g., UE #2-1 and UE #2-2). For example, terminating the SLPP session may include terminating all programs and activities associated with the SLPP session. In response to receiving the indication, each second UE (e.g., UE #2-1 and UE #2-2) may discard SLPP messages stored for the SLPP session and stop ongoing SLPP transactions for the SLPP session.

[0078] The first UE may abandon a second UE in the group of specific second UEs from which an SLPP acknowledgment including a sequence number of an SLPP message has not been received (e.g., the second UE fails to decode at least one of an indicator or a sequence number) (e.g., stop or abort the SLPP session or SLPP transaction with the second UE), and continue the SLPP session with other second UEs.

[0079] The first UE may retransmit the SLPP message to a second UE in the set of specific second UEs from which the SLPP acknowledgment including the sequence number of the SLPP message has not been received (e.g., the second UE fails to decode at least one of the indicator or the sequence number) via an existing unicast connection between the first UE and the second UE.

[0080] If there is no existing unicast connection between the first UE and a second UE in the group of specific second UEs from which an SLPP confirmation including the sequence number of the SLPP message has not been received (for example, the second UE fails to decode at least one of the indicator or the sequence number), the first UE may trigger establishment of a unicast connection with the second UE and retransmit the SLPP message to the second UE via the unicast connection.

[0081] exist Figure 3 In an example, if the group of specific second UEs only includes all second UEs among the multiple second UEs that are within the minimum communication range of the multicast service, then for the second UE outside the minimum communication range of the multicast service, the SLPP confirmation from the second UE is not counted by the first UE for determining the retransmission of the SLPP message, and if no SLPP confirmation is received from the second UE after all retransmissions, then the first UE does not need to handle this second UE.

[0082] Figure 4 An exemplary SLPP error handling procedure according to some embodiments of the present application is described.

[0083] Figure 4 The method in the example may be performed by a first UE (e.g., UE#1) and multiple second UEs (e.g., UE#2-1 and UE#2-2). The first UE may refer to a transmitter (or transmitting UE) that transmits the SLPP message. Each second UE may refer to a receiver (or receiving UE) that receives the SLPP message. In some examples, the first UE may refer to an anchor UE, and each second UE may refer to a target UE. In some other examples, the first UE may refer to a target UE, and each second UE may refer to an anchor UE. In some embodiments of the present application, each of the first UE and one or more second UEs may also be referred to as an endpoint. Although for illustration purposes Figure 4 The two second UEs are depicted in Figure 4The procedure described in the embodiment may involve any number of second UEs. Although the method is described at the system level using three UEs, those skilled in the art will appreciate that the operations implemented in the first UE and the operations implemented in the two second UEs may be implemented separately and combined by other devices having similar functions.

[0084] exist Figure 4 Before the steps shown in FIG. 1 , a first UE (e.g., UE#1) and a plurality of second UEs (e.g., UE#2-1 and UE#2-2) may establish an SLPP session between them. That is, the first UE may establish an SLPP session with the plurality of second UEs, or any second UE in the plurality of second UEs may establish an SLPP session with the first UE and other second UEs in the plurality of second UEs. In other words, when an SLPP session has been established between the first UE and the plurality of second UEs, Figure 4 That is, the first UE and the plurality of second UEs are in a group and in an established SLPP session.

[0085] In step 401, a first UE (eg, UE#1) may multicast an SLPP message in an SLPP session to multiple second UEs (eg, UE#2-1 and UE#2-2). The SLPP message may include a sequence number of the SLPP message.

[0086] Therefore, in step 401, each second UE (e.g., UE#2-1 and UE#2-2) may receive the SLPP message multicast from the first UE. In response to receiving the SLPP message, each second UE may decode the SLPP message. In the event that the second UE detects an error in the SLPP message, in step 402, the second UE may transmit an indication indicating the error in the SLPP message to the first UE. The error may include at least one of the following: a decoding error, a segmentation error, a parameter value error, etc. Figure 4 In the example of , UE#2-1 may detect an error in the SLPP message and transmit an indication indicating the error in the SLPP message to UE#1 in step 402.

[0087] Therefore, in step 402, the first UE may receive at least one indication indicating an error of the SLPP message from at least one second UE among the plurality of UEs. Figure 4 Only one indication received by the first UE is described as an example.

[0088] In response to receiving an indication indicating an error of the SLPP message from the second UE (eg, an indication from UE# 2 - 1 ), the first UE may perform one of the following operations in step 403 .

[0089] The first UE may terminate the SLPP session and multicast an indication indicating that the SLPP session has been terminated to multiple second UEs (e.g., UE #2-1 and UE #2-2). For example, terminating the SLPP session may include terminating all programs and activities associated with the SLPP session. In response to receiving the indication, each second UE (e.g., UE #2-1 and UE #2-2) may discard SLPP messages stored for the SLPP session and stop ongoing SLPP transactions for the SLPP session.

[0090] The first UE may determine that the SLPP transaction associated with the SLPP message has failed, and multicast the ID of the failed SLPP transaction to multiple second UEs (e.g., UE #2-1 and UE #2-2). In response to receiving the ID of the failed SLPP transaction multicast from the first UE, each second UE (e.g., UE #2-1 and UE #2-2) may discard the stored SLPP message for the failed SLPP transaction. In some cases, the first UE may regenerate the SLPP message for the failed SLPP transaction and multicast the regenerated SLPP message to the multiple second UEs.

[0091] The first UE may abandon the second UE (e.g., UE#2-1) indicating the error of the SLPP message (e.g., stop or terminate the SLPP session or SLPP transaction with the second UE) and continue the SLPP session with the other second UEs (e.g., UE#2-2) among the plurality of second UEs.

[0092] According to some embodiments of the present application, a transmitting UE transmitting an SLPP message may determine a broadcast type (multicast, broadcast, or unicast) for the SLPP message. Then, the transmitting UE may transmit the SLPP message according to the determined broadcast type. For example, when executing Figure 2 Step 201, Figure 3 Step 301 or Figure 4 Prior to step 401 in FIG. 4 , UE#1 may determine that the broadcast type for the SLPP message is multicast, and then multicast the SLPP message. In some examples, the broadcast type for the SLPP message may be determined by the SLPP layer. In some examples, the SLPP layer may indicate the broadcast type for the SLPP message to an upper layer.

[0093] In some embodiments, the transmitting UE may determine that the broadcast type for the SLPP message in the SLPP session is groupcast based on at least one of the following:

[0094] Type of SLPP message: For example, when the SLPP message is associated with a capability transfer procedure, an assistance data transfer procedure, or a location information transfer procedure, the transmitting UE may determine that the broadcast type of the SLPP message is multicast;

[0095] The group layer 2 ID of the positioning group associated with the SLPP session maintained by the transmitting UE (or associated with the location service associated with the SLPP session);

[0096] The broadcast layer 2 ID associated with the location service associated with the SLPP session maintained by the transmitting UE;

[0097] The number of UEs to which the SLPP message is to be transmitted is greater than 1;

[0098] There is no unicast connection between the transmitting UE and the UE to which the SLPP message is to be transmitted; or

[0099] Type of transmitting UE: For example, when the transmitting UE is an RSU, the transmitting UE may determine that the broadcast type of the SLPP message is groupcast.

[0100] Figure 5 A simplified block diagram illustrating an exemplary apparatus 500 for SL positioning according to some embodiments of the present application. In some embodiments, the apparatus 500 may be or include at least a portion of a UE (eg, a transmitting UE or a receiving UE as described above).

[0101] refer to Figure 5 , the apparatus 500 may include at least one transceiver 502 and at least one processor 506. The at least one transceiver 502 may be coupled to the at least one processor 506.

[0102] Although elements such as transceiver 502 and processor 506 are described in the singular in this figure, the plural form is contemplated unless limitation to the singular is explicitly stated. In some embodiments of the present application, transceiver 502 may be divided into two devices, such as a receive circuit system (or receiver) and a transmit circuit system (or transmitter). In some embodiments of the present application, apparatus 500 may further include an input device, a memory, and / or other components. Transceiver 502 and processor 506 may be configured to perform any of the methods described herein (e.g., regarding Figures 2 to 4 or other methods described in the Examples of this application).

[0103] According to some embodiments of the present application, the apparatus 500 may be a transmitting UE (eg, an anchor UE or a target UE), and the transceiver 502 and the processor 506 may be configured to perform the operations described in relation to Figures 2 to 4 The operation of transmitting UE in any of the described methods or other methods described in the embodiments of the present application. For example, the processor 506 is configured to: establish an SLPP session with multiple receiving UEs; and multicast SLPP messages in the SLPP session to the multiple receiving UEs using the transceiver 502.

[0104] According to some embodiments of the present application, the device 500 may be a receiving UE (eg, an anchor UE or a target UE), and the transceiver 502 and the processor 506 may be configured to perform the following steps: Figures 2 to 4 The operation of the receiving UE in any of the described methods or other methods described in the embodiments of the present application. For example, the processor 506 is configured to: establish an SLPP session with the transmitting UE and one or more other receiving UEs; and receive an SLPP message in the SLPP session from the transmitting UE using the transceiver 502.

[0105] In some embodiments of the present application, the apparatus 500 may further include at least one non-transitory computer-readable medium. In some embodiments of the present disclosure, the non-transitory computer-readable medium may store thereon computer-executable instructions to enable the processor 506 to implement any of the methods described above. For example, when the computer-executable instructions are executed, the processor 506 may interact with the transceiver 502 to perform, for example, the instructions regarding Figures 2 to 4 The operations of the methods described or other methods described in the examples of this application.

[0106] The method according to any embodiment of the present application may also be implemented on a programmed processor. However, the controller, flow chart and module may also be implemented on a general or special-purpose computer, a programmed microprocessor or microcontroller and peripheral integrated circuit elements, an integrated circuit, a hardware electronic or logic circuit (such as a discrete element circuit), a programmable logic device, etc. In general, any device on which resides a finite state machine capable of implementing the flow chart shown in the figure can be used to implement the processor function of this application. For example, an embodiment of the present application provides an apparatus for SL positioning, which includes a processor and a memory. Computer programmable instructions for implementing the method for SL positioning are stored in the memory, and the processor is configured to execute the computer programmable instructions to implement the method for SL positioning. The method for SL positioning may be any method as described in the present application.

[0107] Alternative embodiments preferably implement the methods according to embodiments of the present application in a non-transitory computer-readable storage medium storing computer programmable instructions. The instructions are preferably executed by a computer-executable component that is preferably integrated with a network security system. The non-transitory computer-readable storage medium may be stored on any suitable computer-readable medium, such as RAM, ROM, flash memory, EEPROM, optical storage device (CD or DVD), hard drive, floppy disk drive, or any suitable device. The computer-executable component is preferably a processor, but the instructions may alternatively or additionally be executed by any suitable dedicated hardware device. For example, an embodiment of the present application provides a non-transitory computer-readable storage medium having computer programmable instructions stored therein. The computer programmable instructions are configured to implement the method for SL positioning according to any embodiment of the present application.

[0108] Although the present application has been described using specific embodiments thereof, it is apparent that many alternatives, modifications, and variations may be apparent to those skilled in the art. For example, the various components of an embodiment may be interchanged, added, or replaced in other embodiments. Furthermore, the operation of the disclosed embodiments does not require all elements of each figure. For example, it will enable one of ordinary skill in the art of the disclosed embodiments to make and use the teachings of the present application by simply adopting the elements of the independent claims. Therefore, the embodiments of the present application as set forth herein are intended to be illustrative and not restrictive. Various changes may be made without departing from the spirit and scope of the present application.

[0109] In the present disclosure, for example, relational terms such as "first", "second" can only be used to distinguish an entity or action from another entity or action, and do not necessarily require or imply any actual this relationship or order between such entities or actions. The term "comprises / comprising" or any other variation thereof is intended to encompass non-exclusive inclusion, so that the process, method, article or equipment comprising a list of elements not only comprises those elements but also may comprise other elements that are not clearly listed or that are intrinsic to this process, method, article or equipment. Elements beginning with "a / an" etc. do not exclude the presence of additional identical elements in the process, method, article or equipment comprising the elements without more constraints. In addition, the term "another" is defined as at least second or more. As used herein, the terms "comprises", "having" etc. are defined as "comprising".

Claims

1. A first user equipment UE, comprising: transceiver; and a processor coupled to the transceiver and configured to: Establishing a sidelink SL positioning protocol SLPP session with multiple second UEs; and The SLPP message in the SLPP session is multicasted to the plurality of second UEs using the transceiver. 2 . The first UE according to claim 1 , wherein the SLPP message includes an indicator indicating that confirmation of the SLPP message is requested and a sequence number of the SLPP message.

3. The first UE of claim 2, wherein the processor is further configured to: In response to receiving an SLPP acknowledgment including the sequence number of the SLPP message from each of one or more second UEs among the plurality of second UEs, multicasting, using the transceiver, a next SLPP message in the SLPP session to the plurality of second UEs, wherein the one or more second UEs include all of the plurality of second UEs or all of the plurality of second UEs within a minimum communication range of a multicast service.

4. The first UE of claim 3, wherein the processor is further configured to perform: Step (1): determining whether an SLPP acknowledgment including the sequence number of the SLPP message has not been received from at least one second UE of the one or more second UEs before a certain time period has passed since the last transmission of the SLPP message; and Step (2): In response to determining that an SLPP confirmation including the sequence number of the SLPP message has not been received from at least one second UE of the one or more second UEs before the time period has passed since the last transmission of the SLPP message, retransmitting the SLPP message to the multiple second UEs using the transceiver.

5. The first UE of claim 4, wherein the processor is further configured to: Step (1) and step (2) are repeatedly performed until a SLPP confirmation including the sequence number of the SLPP message is received from each of the one or more second UEs, or a maximum number of retransmissions of the SLPP message is reached.

6. The first UE of claim 5 , wherein in response to reaching the maximum number of retransmissions of the SLPP message, the processor is further configured to: terminating the SLPP session and multicasting, using the transceiver, an indication that the SLPP session is terminated to the plurality of second UEs; discarding a second UE from which an SLPP confirmation including the sequence number of the SLPP message has not been received among the one or more second UEs; retransmitting the SLPP message via an existing unicast connection to the second UE from which the SLPP acknowledgment including the sequence number of the SLPP message has not been received; or triggering establishment of a unicast connection with the second UE from which the SLPP confirmation including the sequence number of the SLPP message has not been received, for retransmitting the SLPP message to the second UE.

7. The first UE of claim 1 , wherein the processor is further configured to: receiving, with the transceiver, an indication indicating an error in the SLPP message from a second UE of the plurality of second UEs; and In response to receiving the indication: terminating the SLPP session and multicasting, using the transceiver, an indication that the SLPP session is terminated to the plurality of second UEs; determining that a SLPP transaction associated with the SLPP message has failed, and multicasting, using the transceiver, an identity ID of the failed SLPP transaction to the plurality of second UEs; or The second UE is abandoned and the SLPP session of other second UEs in the plurality of second UEs is continued.

8. The first UE of claim 1 , wherein the processor is further configured to determine that the broadcast type for the SLPP message is groupcast based on at least one of: The type of the SLPP message; a group layer 2 ID of a positioning group associated with the SLPP session maintained by the first UE; a broadcast layer 2 ID associated with a location service associated with the SLPP session maintained by the first UE; the number of second UEs to which the SLPP message is to be transmitted is greater than 1; There is no unicast connection between the first UE and a second UE to which the SLPP message is to be transmitted; or The type of the first UE.

9. A second user equipment UE, comprising: transceiver; and a processor coupled to the transceiver and configured to: Establishing a Sidelink Positioning Protocol (SLPP) session with the first UE and one or more other second UEs; and Receive, with the transceiver, an SLPP message in the SLPP session multicast from the first UE. 10 . The second UE according to claim 9 , wherein the SLPP message includes an indicator indicating that confirmation of the SLPP message is requested and a sequence number of the SLPP message.

11. The second UE of claim 10, wherein the processor is further configured to transmit, with the transceiver, an SLPP acknowledgement including the sequence number of the SLPP message in response to receiving the SLPP message and successfully decoding the indicator and the sequence number.

12. The second UE of claim 10 , wherein if the second UE fails to decode at least one of the indicator or the sequence number, the processor is further configured to: receiving the SLPP message retransmitted from the first UE via an existing unicast connection; or A unicast connection is established with the first UE, and the SLPP message retransmitted from the first UE is received via the unicast connection.

13. The second UE of claim 9, wherein the processor is further configured to: In response to detecting an error in the SLPP message, transmitting, with the transceiver, an indication indicating the error in the SLPP message to the first UE.

14. The second UE of claim 9, wherein the processor is further configured to: In response to receiving an indication multicast from the first UE indicating that the SLPP session is terminated, discarding SLPP messages stored for the SLPP session and stopping ongoing SLPP transactions for the SLPP session; or In response to receiving the identity ID of the failed SLPP transaction multicasted from the first UE, discarding the SLPP message stored for the failed SLPP transaction.

15. A method performed by a first user equipment (UE), comprising: Establishing a sidelink SL positioning protocol SLPP session with multiple second UEs; and Multicast the SLPP message in the SLPP session to the multiple second UEs.

Images