Enhanced ranging and positioning services in wireless networks

Abstract

The present invention relates to a wireless system and method for obtaining a distance or position estimate of a target mobile device (10) within a wireless network wherein the apparatus is adapted to: request a ranging or positioning service from a positioning constellation (60) formed by one or more ranging-enabled anchor devices (14) and / or access devices (20) of the wireless network; receiving one or more response multicast / broadcast messages; distance or position estimation or ranging measurements are performed based on information in the at least one response broadcast message.

Description

Technical Field

[0001] The present invention relates to ranging and positioning services in wireless networks, for example but not limited to cellular networks, such as fifth generation (5G) or higher generation networks. Background Art

[0002] Ranging is a process of measuring the distance and / or angle between two wireless devices based on radio parameters (e.g., signal quality, channel conditions, round-trip time, etc.). In wireless systems, the accuracy of ranging measurements may be directly related to the link quality of the radio channel used, the calibration of the ranging process used, or the hardware capabilities of the devices used in terms of antenna design, energy, and computing resources. In addition, the power consumption of the ranging process may be directly related to the operating frequency, duty cycle, and message repetition of the ranging service from one device to another. Due to this direct dependency on dynamic system parameters, the accuracy and power consumption of ranging in wireless devices may become unpredictable and more often negatively affected. In particular, in cases where ranging measurements are used to derive the location coordinates of the device (e.g., geographic coordinates), the accuracy of the ranging service is crucial in determining the precise location coordinates.

[0003] Wireless standards provide standardized technologies to support peer-to-peer ranging, with requirements outlined through multiple use cases, such as those described in 3GPP specification TR 22.855, "Study on Ranging-based Services." However, challenges remain in using specific ranging constellations to improve location services. Examples of these challenges include how to efficiently and securely share or distribute configuration parameters or measurements. Another challenge involves authorization and privacy checks for access to ranging or positioning-related parameters. Other challenges involve determining the process for distributing certain parameters, such as positioning-related configuration parameters or system information parameters. Summary of the Invention

[0004] It is an object to address the above challenges to provide an improved position estimate for deriving position information, e.g. from ranging measurements.

[0005] This object is achieved by an apparatus as claimed in claim 1 , by a mobile communication device as claimed in claim 15 , by a method as claimed in claim 20 and by a computer program product as claimed in claim 37 .

[0006] According to a first aspect, an apparatus for obtaining a range or position estimate of a target mobile device within a wireless network is proposed, wherein the apparatus is adapted to:

[0007] - requesting ranging or positioning services from a ranging constellation formed by one or more anchor devices with ranging capabilities of the wireless network through a ranging or positioning request;

[0008] - receiving at least one multicast / broadcast message via the PC5 communication interface;

[0009] - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message,

[0010] The multicast / broadcast message includes:

[0011] - encrypted data protecting said information contained in said multicast / broadcast message,

[0012] - a group member ID assigned by a management entity or randomly generated by the sender of said multicast / broadcast message, and

[0013] - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

[0014] According to a second aspect of the present invention, an apparatus for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the apparatus is adapted to:

[0015] requesting, via a ranging or positioning request, ranging or positioning services from a positioning constellation formed by one or more anchor devices and access devices having ranging capabilities of the wireless network;

[0016] receiving one or more multicast / broadcast messages from an access device;

[0017] A distance or position estimation or ranging measurement is performed based on information in the at least one responsive multicast / broadcast message.

[0018] According to a third aspect of the present invention, an apparatus for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the apparatus is adapted to:

[0019] - receiving a ranging or positioning request for a ranging or positioning service from a requesting device, the ranging or positioning service involving a ranging constellation formed by one or more anchor devices having ranging capabilities of the wireless network;

[0020] - Send at least one multicast / broadcast message via the PC5 communication interface;

[0021] - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message,

[0022] The multicast / broadcast message includes:

[0023] - encrypted data protecting said information contained in said multicast / broadcast message,

[0024] - a group member ID assigned by a management entity or randomly generated by said means of said multicast / broadcast message, and

[0025] - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

[0026] According to a fourth aspect of the present invention, a method for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the method comprises:

[0027] - requesting ranging or positioning services from a ranging constellation formed by one or more anchor devices with ranging capabilities of the wireless network through a ranging or positioning request;

[0028] - receiving at least one multicast / broadcast message via the PC5 communication interface;

[0029] - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message,

[0030] The multicast / broadcast message includes:

[0031] - encrypted data protecting said information contained in said multicast / broadcast message,

[0032] - a group member ID assigned by a management entity or randomly generated by the sender of said multicast / broadcast message, and

[0033] - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

[0034] According to a fifth aspect of the present invention, a method for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the method comprises:

[0035] - receiving a ranging or positioning request for a ranging or positioning service from a ranging constellation formed by one or more anchor devices having ranging capabilities of the wireless network;

[0036] - Send at least one multicast / broadcast message via the PC5 communication interface;

[0037] - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message,

[0038] The multicast / broadcast message includes:

[0039] - encrypted data protecting said information contained in said multicast / broadcast message,

[0040] - a group member ID assigned by a management entity or randomly generated by said means of said multicast / broadcast message, and

[0041] - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

[0042] According to a sixth aspect of the present invention, a method for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the method comprises:

[0043] - requesting ranging services from a positioning constellation formed by one or more anchor devices and access devices with ranging capabilities of the wireless network;

[0044] - receiving at least one multicast / broadcast message from an access device;

[0045] - Performing distance or position estimation or ranging measurements based on at least one multicast / broadcast message.

[0046] According to a seventh aspect of the present invention, an apparatus in an access device for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the apparatus is adapted to:

[0047] receiving a ranging or positioning request for a ranging or positioning service involving a positioning constellation formed by one or more anchor devices and access devices having ranging capabilities of the wireless network;

[0048] Send one or more multicast / broadcast messages;

[0049] A distance or position estimation or ranging measurement is performed based on information in the at least one responsive multicast / broadcast message.

[0050] According to an eighth aspect of the present invention, a method for obtaining a distance or position estimate of a target mobile device within a wireless network is provided, wherein the method comprises an access device performing the following operations:

[0051] - receiving a request for a ranging service from a requesting device, the ranging service relating to a positioning constellation formed by one or more anchor devices and access devices of the wireless network having ranging capabilities;

[0052] - Send at least one multicast / broadcast message;

[0053] - Performing distance or position estimation or ranging measurements based on information contained in said multicast / broadcast message.

[0054] Therefore, a management entity (e.g., a wireless access device or a base station or a network function in a core network) configures one or more network devices (e.g., a UE) as anchor devices to form a ranging constellation, thereby supporting ranging services, location services, and / or ranging-based positioning services (i.e., a combination of ranging and location service functions). Thus, positioning accuracy can be improved using simple ranging measurements between devices that are locally or centrally coordinated. In addition to improving positioning and ranging accuracy, ranging constellations also help reduce power consumption of the involved (mobile) network devices by combining ranging and location services. In particular, the time at which position information can be derived from ranging measurements and the method for ranging-based position estimation can be determined.

[0055] Ranging services, location services, and / or ranging-based positioning services can be provided by a different network than the wireless network that collects ranging measurements. They can also be provided by third-party applications that calculate location based on these measurements. Furthermore, the geographic area of ​​the positioning service can depend on the capabilities of the anchor device and / or the characteristics of the environment in which the anchor device is deployed. This does not need to be known in advance by the network and can be optionally configured.

[0056] According to a first option, which can be combined with any of the first to eighth aspects of the present invention, the multicast / broadcast message comprises a counter, such as a time-based counter, as an input to the encryption algorithm and / or the integrity algorithm.

[0057] According to a second option, which can be combined with the first option or with any of the first to eighth aspects, the apparatus may be adapted to determine whether the group member ID is generated by the management entity or by the sender based on a group member ID length.

[0058] According to a third option, which can be combined with any of the first or second options or with any of the first to eighth aspects, if the selected integrity algorithm is the NULL algorithm, the MIC is not set to zero.

[0059] According to a fourth option, which can be combined with any of the preceding options or with any of the first to eighth aspects, the apparatus is adapted to verify message freshness by checking the counter.

[0060] According to a fifth option, which can be combined with any of the previous options or with any of the first to eighth aspects, the message comprises a randomized or scrambled device specific identifier.

[0061] According to the sixth option which can be combined with any of the preceding options or any of the first to eighth aspects, the ranging or positioning request includes one or more of the following:

[0062] The ranging and positioning capabilities of the device,

[0063] (Ranging) Group ID,

[0064] The type of service requested (ranging / positioning),

[0065] The requested reply type (unicast / broadcast / ...),

[0066] Identification / authentication / authorization credentials,

[0067] instructions to emergency services,

[0068] Preference for NULL-safe algorithms.

[0069] According to the seventh option, which can be combined with any of the preceding options or with any of the first to eighth aspects, the apparatus is adapted to receive at least one configuration message having configuration parameters to receive the one or more multicast / broadcast messages through the access device, wherein the configuration message is a ranging service confirmation, and the ranging service confirmation includes: configuration parameters such as one or more multicast / broadcast keys or a selected security algorithm, or security parameters for protecting multicast / broadcast messages in the RAN and in the ranging constellation.

[0070] According to an eighth option, which may be combined with the fifth or seventh option or with any one of the first to eighth aspects, the multicast / broadcast message is an MBS message or an RRC broadcast message or an SIB.

[0071] According to the ninth option, which can be combined with any of the preceding options or with any of the first to eighth aspects, the multicast / broadcast message includes an indication of the ranging positioning capabilities (e.g., physical layer capabilities) or assistance data or cryptographic values ​​(e.g., keys, authorization tokens, etc.) of the anchor device and / or the devices in the positioning constellation.

[0072] According to the tenth option, which can be combined with any of the preceding options or with any of the first to eighth aspects, the multicast / broadcast message is protected by one or more of encryption, scrambling and integrity protection, and wherein the apparatus is adapted to process the protected multicast / broadcast message to successfully decode the multicast / broadcast message.

[0073] According to an eleventh option, which may be combined with any of the fifth or seventh or eighth or ninth options, the key used to protect said multicast / broadcast message is used to securely transmit a seed or to serve as a seed to derive a group key for subsequent multicast / broadcast communications in said ranging constellation.

[0074] According to an eleventh option which may be combined with any of the fifth or seventh or eighth or ninth or tenth or eleventh options, the device is adapted to:

[0075] - obtaining a counter C1 by combining a value C0 received in a protected message or derived from all or part of another counter and / or a value D0 received in said broadcast message and / or a data segment counter,

[0076] - obtaining a decryption key and / or an integrity key by applying a key derivation function to a preconfigured key and said counter C1,

[0077] - applying an encryption algorithm (e.g. AES or NEA in counter mode) together with said counter C1 and decryption using said key to decrypt said data in said broadcast message,

[0078] - applying the counter C1 and the integrity key to calculate the MIC by means of the KDF or NIA algorithm and verifying the integrity of the received response broadcast message,

[0079] - If the integrity verification is successful, the decrypted data is passed to the upper layer.

[0080] According to a thirteenth option, which may be combined with any one of the fifth or seventh or eighth or ninth or tenth or eleventh or twelfth options, the ranging service is bundled to the MBS service.

[0081] It should be noted that the above-mentioned apparatus can be implemented based on an arrangement of discrete hardware circuits, integrated chips or chip modules having discrete hardware components, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer-readable medium or downloaded from a network (such as the Internet).

[0082] It shall be understood that the apparatus of claim 1, claim 7, 16, 20, 22, 25, 34 or 50, the method of claim 17, 18, 19, 21, 24, 33, 39 or 40 and the computer program product of claim 51 may have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

[0083] It shall be understood that a preferred embodiment of the invention can also be any combination of the dependent claims or the above-described embodiments with the respective independent claim.

[0084] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] In the following figure:

[0086] Figure 1 Schematically illustrates different concepts for providing ranging services to mobile devices with or without network coverage;

[0087] Figure 2 A diagram schematically shows different directions in a spherical coordinate system;

[0088] Figure 3 A timing diagram schematically illustrates the data transmission between a transmitter and a receiver to explain the round-trip time concept;

[0089] Figure 4 Schematically shows an illustration of the angle of arrival concept based on phase difference considerations;

[0090] Figure 5 Schematically illustrates a block diagram of a wireless system for providing ranging and / or positioning services according to various embodiments;

[0091] Figure 6 Schematically illustrates a network architecture according to various embodiments, wherein a mobile terminal approaches a mobile terminal constellation to be assisted by a ranging service for location coordinates; and

[0092] Figure 7 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0093] Figure 8 An example conceptual architecture of an anchor UE supporting a subset of LMF functionality as a proxy is schematically illustrated.

[0094] Figure 9 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0095] Figure 10 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0096] Figure 11 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0097] Figure 12 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0098] Figure 13 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0099] Figure 14 A signaling and processing diagram for ranging-based positioning services according to various embodiments is schematically shown.

[0100] Figure 15The signaling and processing diagram of the positioning service based on ranging and / or positioning on the UE to the network relay according to various embodiments is schematically shown.

[0101] Figure 16 The signaling and processing diagram of the positioning service based on ranging and / or positioning on the UE to the network relay according to various embodiments is schematically shown. DETAILED DESCRIPTION

[0102] Embodiments of the present invention are now described based on ranging and / or positioning (sometimes also referred to as "positioning") services of cellular networks, where, for example, 4G network elements can be incorporated into the proposed 5G solution. In addition, at least some of the following embodiments are described based on 5G New Radio (5GNR) radio access technology. However, the present invention can also be used in combination with other wireless technologies (e.g., IEEE 802.11 / Wi-Fi or IEEE 802.15.4 / Ultra-Wideband Communication (UWB)) in which positioning of devices or distance measurement between devices is provided or can be introduced.

[0103] Throughout this disclosure, the term "wireless network" is intended to refer to the entire network system (e.g., a 4G or 5G system) including communication devices (e.g., UEs), the Radio Access Network (RAN), and the Core Network (CN). In addition, the term base station and the abbreviations "eNB" (4G terminology) and "gNB" (5G terminology) are intended to refer to access devices such as cellular base stations or WiFi access points or UWB PAN coordinators. The eNB / gNB is part of the RAN, which provides an interface for functions in the CN. The RAN is part of a wireless communication network. It implements the Radio Access Technology (RAT). Conceptually, it sits between communication devices such as mobile phones, computers, or any remotely controlled machines, and provides connectivity to their CN. The CN is the core part of the communication network, providing a variety of services to customers interconnected via the RAN. More specifically, it directs communication flows through the communication network and possibly other networks.

[0104] Furthermore, in this disclosure, the terms "base station" (BS) and "network" may be used synonymously. This means, for example, that when a "network" is written to perform a particular operation, it may be performed by a CN function of a wireless communication network, or by one or more base stations that are part of such a wireless communication network, or vice versa. This may also mean that part of the function is performed by the CN function of the wireless communication network, and part of the function is performed by a base station.

[0105] In the 3GPP specifications 23.303, 23.304, 24.334 and 24.554 for 4G and 5G networks respectively, so-called proximity services (ProSe) functions are defined to enable, among other things, the connection of cellular communication devices (e.g., UEs) that are temporarily out of coverage of an access device (eNB). One specific function is called ProSe UE to network relay or relay UE. A relay UE is a communication device that helps another out-of-coverage (OoC) UE communicate with an eNB (i.e., an access device) by relaying application and network data traffic in both directions between the OoC UE and the eNB. Local communication between the relay UE and the OoC-UE is called D2D communication or sidelink communication or PC5 communication. The abbreviation "PC5" denotes the interface for sidelink communication defined by ProSe. In addition, the abbreviation "UL" is used for the uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used for the downlink direction from an access device (e.g., eNB, gNB) to a communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UE).

[0106] Once the relay relationship is established, the OoC-UE connects via the relay UE and plays the role of a "remote UE". This means that the remote UE has an indirect network connection to the CN instead of a direct network connection as in the normal case (see 3GPP specification TS 22.261 v16.10.0).

[0107] In addition, 3GPP specifications TR 23.733 v15.1.0 and TR 36.746 v15.1.1 provide research on architectural enhancements, such as enabling IoT devices (as remote UEs) to operate at very low power by using relay UEs to connect to a wider network. Since the relay UEs are physically very close, very low power transmissions can be used to reach the relay UEs. This work also includes improvements to the security, speed, and stability of ProSe. These extensions of ProSe are called enhanced ProSe ("eProSe").

[0108] ProSe can also be used for direct communication between two UEs. Additional radio-level details on ProSe, V2X, and sidelink communications can be found in 3GPP specifications TR 37.985, TS 38.300, and TR 38.836.

[0109] Ranging can be defined as a process of measuring the distance and / or relative bearing angle between two wireless devices in three-dimensional space. In the initially mentioned specification TR 22.855 "Study on Ranging-based Services", ranging-based services are defined as applications that utilize the distance between two UEs and / or the direction of one UE to another UE. These ranging-based services can be supported with or without network coverage. In addition to the measurement of distance and bearing angle, a related measurement is whether the two wireless devices are in direct line of sight, as this is relevant for many use cases where the UEs are assumed to interact with each other if they are in line of sight (e.g. in the same room).

[0110] The term "ranging reference signal" is used herein to refer to a signal used to determine the distance and / or angle between two devices that may be connected via a device-to-device connection (e.g., using a sidelink and / or PC5) rather than an infrastructure connection (e.g., using a Uu interface). The ranging reference signal may be a position reference signal and / or a sounding reference signal or other signal (e.g., a signal used for round-trip time (RTT) measurement) that may be used to determine the distance and / or angle between devices, possibly using resources used for device-to-device (e.g., sidelink) communication / discovery (which may be configured or granted by an access device) and / or resources specifically reserved for sending reference signals or other signals that may be used to determine the distance and / or angle between devices.

[0111] The terms "ranging-capable device" and "ranging-capable UE" are used herein to refer to a device having a minimum set of components, subsystems and / or functions to perform or support distance measurements and / or angle measurements between itself and another device (e.g., using time difference of arrival, round-trip time, carrier phase, or other measurements / techniques). This set of components, subsystems and / or functions does not always need to be enabled and can be enabled / triggered as needed (e.g., by a request from another device or network function). In addition, the components, subsystems and / or functions may not always be authorized to perform distance measurements. Therefore, the terms "ranging-capable device" and "ranging-capable UE" can also be interpreted as being able to perform distance measurements and / or angle measurements between itself and another device, and being authorized / enabled to do so. In addition, in sentences using the term "having the capability of...", it can also be understood / limited to being enabled and / or authorized.

[0112] Ranging capabilities may vary from device to device. For example, not every device is capable of calculating angles because it requires multiple antennas. The ranging capabilities of the device (which may be exchanged as part of the discovery process) can be used to determine the capabilities of the device and what measurements can be made. Note that angle calculation may need to be an explicit capability rather than a capability based solely on the number of declared antennas. Just because the number of antennas is greater than one does not automatically mean that the device is capable of calculating angles. The calculation of angles may also require sensors (e.g., magnetometers, gyroscopes, accelerometers) to derive the heading and / or angle towards a reference point (such as magnetic north), as well as an angle / heading calibration mechanism. The angle may also indicate an altitude difference, and a reference altitude (e.g., meters above sea level and / or atmospheric pressure, ground information, terrain height data for device location) and an altitude calibration mechanism may be used.

[0113] Chapter: Distance / Angle / Position Calculation Techniques

[0114] Figure 1 AC schematically illustrates different concepts for providing ranging services based on the distance and / or direction (D) between two mobile devices 10, 12 with or without network coverage. The dashed elliptical line shows a perspective view of a circular coverage area around an access device (e.g., gNB) for accessing a 5G cellular network. Figure 1 In A, the first UE 10 is located within the coverage area of ​​the access device 20, while the second UE 12 is located outside the coverage area and therefore has no network coverage.

[0115] exist Figure 1 In B, both the first UE 10 and the second UE 12 have no network coverage.

[0116] exist Figure 1 In C, both the first UE 10 and the second UE 12 are located within the coverage area of ​​the access device 20 and therefore have network coverage.

[0117] Figure 2 A diagram of different directions in a spherical coordinate system is schematically shown.

[0118] The distances and angles between a group of UEs (e.g., observer UE (O-UE) and target UE (T-UE)) can be visualized in a three-dimensional (3D) sphere in a two-dimensional (2D) plane, as shown in Figure 2 The horizontal direction of the target UE (i.e., the azimuth angle (Az)) is the angle formed between the reference direction (RD) and the line from the observer UE to the target UE, which is projected on the same plane as the target reference direction orthogonal to the direction of the zenith (Z). The elevation angle of the target UE (i.e., the elevation angle (El)) is the angle above the horizontal plane, that is, the angle formed between the horizontal target reference direction and the direction from the origin of the observer UE to the target UE.

[0119] For example, in Mario H. The ranging measurement between two UEs described in the ranging study by Garcia et al., “A Tutorial on 5G NR V2X Communications” (DOI 10.1109 / COMST.2021.3057017), may produce two parameters: the distance between the two UEs (in meters) and the angle (in degrees) at which the target UE is elevated from the observer UE in the 3D plane.

[0120] There are multiple use cases that require distance accuracy within 10cm (i.e., sub-nanosecond time measurement accuracy) within an effective ranging distance of 20m, and a tolerance of up to ±2° in the horizontal and vertical planes within a coverage range of -45° to +45° angle of arrival (AoA) relative to a reference direction of the ranging device. In some use cases, a local coordinate system for ranging UEs is proposed, where the distances and angles measured from the ranging service are converted to position coordinates. It is expected that UEs participating in ranging will move at various speeds (e.g., from 1m / s to 10m / s), and multiple concurrent ranging operations can be completed between multiple UEs in a given area, and a UE can perform multiple concurrent ranging operations with other UEs present in the area.

[0121] So-called "peer ranging" can be accomplished in a variety of ways, including but not limited to:

[0122] i. Two-way ranging: This is a process in which two devices A and B transmit data packets and acknowledgment packets to each other. This technique accounts for time delays due to natural radio signal propagation and processing delays on device B (i.e., the time it takes for device B to resend a packet to device A). The one-way time of flight is then calculated on device A as half the difference between a) the time it takes for device A to send a packet and receive the next packet from B, and b) the time it takes for device B to receive a packet from A and send its response packet back to A. Device B can include information in its response packet so that A can calculate the time it took. At device A, the one-way time of flight can then be used to calculate the distance between devices A and B. Device B can perform the same process on device A so that B can also calculate the distance. In this technique, the clocks of the two devices do not need to be synchronized, as processing delays are accounted for by two consecutive packet transmissions, and the distance can be calculated simultaneously on both devices.

[0123] ii. One-way ranging, a process in which at least one packet is sent between a transmitting wireless device A and a receiving wireless device B. These devices are synchronized with each other via a common clock source. The time of flight is then measured as the difference between the reception time at device B and the transmission time at device A. Device A can include a timestamp of its transmission time within the data packet so that device B can calculate this time difference. The accuracy of the ranging depends on the accuracy of the clock synchronization achievable between the two devices.

[0124] Peer-to-peer ranging operations may depend on multiple parameters of wireless communication, such as clock time synchronization between devices, the communication path over which the signal is transmitted (e.g., line of sight (LOS) or non-line of sight (NLOS)), antenna characteristics, operating frequency, transmission power, and receiver sensitivity of the wireless radio. These parameters are also important for general radio communications, resulting in a variety of standardized techniques to achieve the highest communication performance for a given radio. For example, in 3GPP, the Sidelink Radio Resource Protocol as described in specification 36.331 v16.4.1 ensures high-precision clock time synchronization between two sidelink UEs operating in multiple in-coverage and out-of-coverage scenarios.

[0125] Positioning can be defined as the process of determining the location coordinates of wireless devices (such as, but not limited to, mobile phones, wearables, and IoT devices) based on a location coordinate system. After determining the device's location coordinates, mapping functions can be used to locate it on a map. Positioning is often distinguished between absolute positioning (i.e., determining geographic coordinates (location coordinates) based on a standardized geographic coordinate system) or relative positioning (i.e., determining coordinates (e.g., using a local coordinate system) and / or angle plus distance relative to a reference point). Some examples of how to represent absolute or relative position can be found in the 3GPP specification TS 23.032. A classic example is satellite-based location services (e.g., the Global Positioning System (GPS) or the Global Navigation Satellite System (GNSS)), which use at least three of a number of satellites in a Medium Earth Orbit (MEO) satellite constellation to calculate the device's location coordinates using well-known processes such as triangulation and trilateration. The satellites act as clock synchronization sources, and the communication delays of the transmitted packets are used to estimate the location coordinates. Any third-party mapping tool (e.g., OpenStreetMap) can use these coordinates to pinpoint the device's location on a geographic map of the area. In addition, several indoor positioning technologies based on radio frequency technologies (such as Bluetooth, ultra-wideband (UWB) or Wi-Fi) are available, which can locate / determine the coordinates of radio frequency (RF) transmitting tags in indoor environments. The locations of these tags can then be mapped onto an indoor floor plan using indoor coordinates estimated based on RF propagation characteristics (such as time delay, multipath reflections, received signal strength, etc.) measured using RF communication between the tags and anchor nodes placed at pre-known locations in the building.

[0126] Positioning techniques used to obtain the coordinates of the device's current location can be implemented in a variety of ways, but typically include triangulation and / or trilateration based on a set of measured distances and / or angles between the device and a set of other devices or reference points. Distances and angles can be determined using various techniques, including round-trip time (RTT), time of flight (ToF), time difference of arrival (TDoA), angle of arrival / departure (AoA / AoD), and / or combinations thereof:

[0127] The round trip time (RTT) defines the duration from when a data packet is sent by a transmitter (Tx, e.g., an access point / device) to when a receiver (Rx, e.g., a mobile phone / device) receives and acknowledges the same data packet, i.e., until the moment the transmitter receives the acknowledgement. Since data packets propagate at the speed of light (approximately 3.3ns / m) in the air medium, the duration that the data packet propagates in the air is proportional to the actual distance between Tx and Rx. In the case where the internal clocks in Tx and Rx are not synchronized, the one-way time measurement cannot be based on the difference between the sent and received timestamps, because the one-way time measurement will also include timing errors caused by internal clock drift and uncertain clock offset between Tx and Rx. Since the internal clocks of Tx and Rx are not synchronized, when the signal propagates in the reverse direction (i.e., Rx to Tx), the difference in timestamps is affected by the clock offset in the opposite way to that in the forward direction (i.e., TX to RX).

[0128] Figure 3 A timing diagram of data transmission between a transmitter and a receiver is schematically shown to explain the round-trip time concept.

[0129] exist Figure 3 In the timing diagram of , time passes from the upper side to the lower side, and the information flow between the transmitter (Tx) and the receiver (Rx) is represented by the corresponding arrows.

[0130] according to Figure 3 , a data packet (DP) is sent from Tx to Rx at time t1 and is received at Rx at time t2. An acknowledgement (ACK) is sent from Rx to Tx at time t3 and is received at Tx at time t4.

[0131] By simply adding and subtracting the four timestamps t1 to t4, the round trip time (RTT) can be obtained without knowing any clock offset, as shown below:

[0132] RTT = (t4 - t1 + t2 - t3)

[0133] Where t1 is the sending time, t2 is the receiving time, t3 is the sending confirmation time, and t4 is the receiving confirmation time.

[0134] The distance D between Tx and Rx can be estimated by using the following equation:

[0135] 2*D=((t4-t1)-(t3-t2))*c

[0136] where c is the speed of light. Note also that in distance estimation based on RTT measurements, no synchronization between the transmitter and receiver is required. The calculation of a single distance can be extended to two and three dimensions for multiple distance estimates, which can then be converted into estimates of location coordinates (both local and global) when the coordinates of each transmitter are known in advance. Some standardized mechanisms for using RTT-based techniques include Fine Timing Measurement (FTM) defined in IEEE 802.11-2016 and Enhanced Cell ID (E-CID) defined in 3GPP TS 36.133.

[0137] The time of flight (ToF) corresponds to the duration from when a data packet is sent by a transmitter (Tx, e.g., an access point / device) to when the same data packet is received by a receiver (Rx, e.g., a mobile phone / device). Note that this method only considers the forward path (i.e., Tx to Rx) and not the reverse path (i.e., Rx to Tx). In this case, the internal clocks of Tx and Rx (or multiple Tx and Rx) need to be time synchronized so that the timestamp of the received packet can be assumed to be correct and any timing errors caused by internal clock drift and uncertain clock offset between Tx and Rx can be compensated. Assumptions Figure 3 The Tx and Rx in the datagram are synchronized, and the distance D between Tx and Rx can be calculated by the following equation:

[0138] D=(t2-t1)*c

[0139] Where t2 is the timestamp of reception, t1 is the timestamp of transmission, and c is the speed of light. The time of flight can be calculated by Rx knowing the timestamp t1 (which is, for example, included in the message sent or transmitted later) and the timestamp t2 measured by itself. The time of flight can also be calculated by Tx knowing the timestamp t2 (which is, for example, later transmitted by Rx to Tx) and its own measured timestamp t1. The calculation of a single distance can be extended to two-dimensional and three-dimensional space for the estimation of multiple distances, and then when the coordinates of multiple reference devices (acting as transmitters or receivers) are known in advance, the estimates of multiple distances can be converted into estimates of position coordinates (both local and global).

[0140] The arrival time difference corresponds to the difference in the timestamps at which multiple clock-synchronized receivers (Rx, e.g., access points / devices acting as synchronous location reference stations) receive a data packet, whereby the data packet is sent by an asynchronous transmitter (Tx, e.g., a mobile phone / device, or an asynchronous location tag for which the location coordinates are to be determined). Note that the roles can be reversed, e.g., the mobile phone / device can be an asynchronous Rx, while the access point / device can be a synchronous transmitter. Note that a single transmission of a data packet by a transmitter will be received in parallel by several synchronous receivers placed within the coverage area of ​​the transmitter. What is important is that the receivers are clock-synchronized and that the location coordinates of the receivers are known to the central location server, whereas the transmitter for which the location coordinates are to be determined may not be synchronized with the other transmitters or with the receivers. The central location server can receive the arrival time i=0…N of the data packet from each receiver and can calculate the distance difference for any pair of receivers (i, j) for a particular transmitter based on the following equation:

[0141] Δd ij =(d i -d j )=Δt ij *c

[0142] Where c is the speed of light, Δt ij is the difference in arrival time between receiver i and receiver j, d i For receiver i, the Tx to Rx distance is unknown, Δd ij is the difference in Tx to Rx distance between receiver i and receiver j. This calculation can be applied to two-dimensional and three-dimensional space for the estimation of distance difference, which can be converted into position coordinates (both local and global) when the coordinates of the receiver are known in advance. Note that the sender cannot calculate its own position locally on the device, only the location server can calculate the position of the sender using the positioning infrastructure and a synchronized network of receiver nodes. Note that the location server can be located on one of the clock-synchronized receivers. The position of the sender can be transmitted over a separate communication channel (e.g., to the application, to the sender, or to one or more receivers), or can be modified in one of the responses from the receiver to the sender in the same channel used to send the data packet.

[0143] Alternatively or additionally, the receiver may send its measurements (e.g., time of arrival information) instead of the calculated distance and / or angle to a transmitter or location server, which will calculate the resulting distance and / or determine the resulting location coordinates. Some standardized mechanisms using ToF difference-based techniques include Observed Time Difference of Arrival (OTDOA) defined in 3GPP TS 25.305 and TS 36.133, which are typically based on Position Reference Signals (PRS) or Sounding Reference Signals (SRS), and Uplink Time Difference of Arrival (UTDOA) defined in 3GPP TS 25.305.

[0144] In addition to time-based distance estimation, the angle of arrival is derived from the phase information of the RF signal received at the receiver using the antenna array. This phase information can be used to estimate the elevation or azimuth angle that the signal was received in. This angle information can be used to determine the direction from which the signal was transmitted.

[0145] Figure 4 A diagram of the angle of arrival concept based on phase difference considerations is schematically shown.

[0146] exist Figure 4 In the example of , the angle of arrival of the incoming RF signal (indicated by the two diagonal arrows) can be calculated as follows. In principle, a receiver with at least two antennas (separated by a distance d) with different receive phases φ1, φ2 can determine the phase difference Δφ of the received signals at the receiver and then use it to estimate the angle of arrival according to the following equation:

[0147] Δφ=[φ1-φ2]=2π[(dcosθ1) / λ]+2kπ

[0148] Where θ1 is the angle of arrival to be estimated, k is the wave number which can be calculated by k = 2πλ, where λ is the wavelength of the RF signal calculated by λ = c / f, where c is the speed of light and f is the radio frequency of the signal.

[0149] Based on the measured phase difference, a naive approach can be used to estimate the angle of arrival of the RF signal at the receiver using the following equation:

[0150] cosθ1=[(Δφ / 2π)-k]*[λ / d]

[0151] Note that in addition to the above methods, there are several well-known methods for calculating the angle of arrival of RF signals, including but not limited to Bartlett beamforming (see MS Bartlett: "Smoothing Periodograms from Time-Series with Continuous Spectra"), Multiple Signal Classification (MUSIC) (see https: / / en.wikipedia.org / wiki / MUSIC_(algorithm)), distortion estimation (see J. Capon: "High-resolution frequency-wavenumber spectrum analysis", Transactions of the IEEE, Vol. 57, No. 8), and signal and noise subspace estimation. Other complex estimates of AoA can use more than two antennas at the receiver, which enables only one receiver instead of three synchronous receivers to obtain both angle and range measurements based on the RF signal transmitted by an asynchronous transmitter with relatively simple hardware and a single antenna. Similarly, in the case where the transmitter uses multiple antennas, the departure angle (of the signal at the transmitter) can be determined and used for ranging / position estimation.

[0152] The process of obtaining the location coordinates of a device and locating the device on a map using a mapping function is also provided by the location service (LCS) provided in the 3GPP system, where the base station can act as a synchronization source and use various positioning methods to obtain the location coordinates of the device based on radio parameters and special messages, as described in, for example, the 3GPP specification TS23.271 "Functional stage 2 description of Location Services (LCS)", Rel-16 (for 4G) and the 3GPP specification TS23.273 "5G System (5GS) Location Services (LCS); Stage 2", Rel-17 (for 5G).

[0153] The typical difference between location services and ranging services provided by 3GPP systems is that location services can measure the geographic coordinates of a device within the coverage area of ​​a cell (e.g., 1-5 km) and provide good accuracy in outdoor environments where there may be a line of sight (LOS) with a base station, and can fairly model and consider communication paths using channel models for urban and rural environments, while ranging services can measure the distance and / or angle between two devices within a short distance (e.g., 20 m) and provide good accuracy in outdoor and especially indoor environments where the two ranging devices can also be within the line of sight (LOS) of each other.

[0154] The functionality of the location service and the ranging service can be combined to provide, for example, a location service with improved accuracy and better indoor position estimation. The location service or ranging service or a combination thereof can also verify the integrity / measurement accuracy / determination error of the measured distance, angle, position information (e.g., coordinates), etc., and possibly compensate for it, and / or provide the distance, angle, position information to the UE, core network function, application or other location / ranging service, and / or store the distance, angle, position information in non-volatile memory, and / or combine the distance, angle, position information with distance, angle, position information from other sources or generated by various location / ranging mechanisms.

[0155] Note that location services may also provide ranging services (and vice versa), e.g., where the positions of two devices can be observed / determined, e.g., via GNSS, the distance and / or angle between the two devices may be calculated and exposed as part of a ranging service that may allow a device to request the distance and / or angle between itself and another device. In this case, the two devices may still be required to perform ranging measurements between each other to improve the accuracy of the distance and / or angle between the two devices, or to determine deviations from the observed / determined positions.

[0156] The conversion of distance to coordinates can be implemented, for example, based on ranging measurements, through which a first device A can obtain the distance (d) and angle (tc) toward a second device B. If the coordinates of device A are known, and its orientation relative to the coordinate system is known, device A can use the distance and angle measurements between devices A and B to obtain the coordinates of device B.

[0157] For example, in the case of geographic coordinates expressed in radians, assume that the latitude (lat1) and longitude (lon1) of device A are known. Then, when using a spherical Earth approximation model, the geographic coordinates of device B (lat2, lon2) can be calculated using the following equation:

[0158] lat2=asin(sin(lat1)*cos(d)+cos(lat1)*sin(d)*cos(tc))

[0159] dlon=atan2([sin(tc)*sin(d)*cos(lat1)],[cos(d)-sin(lat1)*sin(lat2)])

[0160] lon2=[mod(lon1-dlon+π,2*π)]-π

[0161] Here, the distance d is expressed as a relative distance, equal to the distance measured between A and B divided by the average radius of the Earth.

[0162] As another example, in the case of a local 2D Cartesian coordinate system for a region, we can assume that the X and Y coordinates of device A (x1 and y1, respectively) are known. Then, we can calculate the X / Y position coordinates of device B (x2 and y2, respectively) using the following equations:

[0163] x2=d*cos(alpha)+x1

[0164] y2=d*sin(alpha)+y1

[0165] where all coordinates and distances d are expressed in meters, and the angle (α) towards device B is measured by A.

[0166] Alternatively, depending on the required accuracy and the type of coordinate system used by the application, other concepts such as the reverse Havershine formula, degree length, Molodensky method, and block shift method can be used to complete the conversion of distance to coordinate system coordinates. Current techniques for ranging and position estimation can be improved in the following aspects:

[0167] i. In indoor and deep indoor environments where cellular coverage is very poor, location accuracy is highly dependent on signal path loss and degrades with loss of signal quality. In addition, in remote outdoor environments where the number of base stations is limited and the signal coverage is sparse to no signal, the accuracy of location services deteriorates. In these areas, depending on the positioning method used, triangulation or triangulation of a mobile device (e.g., UE) may require a longer initial lock time in order to be able to receive at least three different signals from at least three different base stations simultaneously. If a mobile device is moving in such a poor coverage area, the continuity and reliability of the location services provided by the base stations may become severely interrupted, causing the service to become unusable for real-time location tracking.

[0168] ii. Ranging accuracy in outdoor environments depends heavily on channel variability and the reflective properties of objects surrounding the device performing the ranging operation. In indoor environments, the user of a mobile device (e.g., UE) can fairly control the environment relative to objects and the surrounding environment before performing ranging between two devices, whereas in outdoor environments, control of the environment is uncertain and, more often, will negatively impact ranging accuracy. In addition, the movement of the mobile device in an outdoor environment may also have a significant impact on ranging accuracy due to possible Doppler effects in the RF propagation channel. Therefore, ranging measurements between two devices in an outdoor environment may become unusable due to the significantly worsening effects in the RF channel.

[0169] In the following, embodiments are described in which ranging and / or positioning concepts are supplemented by using ranging measurements (e.g., distance, angle, and altitude) between a transmitter and a receiver, thereby improving the accuracy of positioning and / or reducing power consumption associated with these concepts.

[0170] Some use cases may require conversion of ranging measurements into location coordinates, which enables UEs that are unable to use positioning services or additional positioning modules to obtain location coordinates derived from the ranging information. In addition, devices with very poor positioning accuracy, especially those in indoor environments, may benefit from ranging, thereby improving positioning accuracy from hundreds of meters to sub-meter accuracy in indoor environments and / or out-of-coverage environments. In addition, precise positioning and continuous tracking of low-power IoT devices is another use case requirement, which can adaptively deliver quality of service (QoS) to mobile UEs based on location, for example, providing high bandwidth at location X and only low bandwidth at location Y. Some identified suitable use cases may require the formation of UE clusters based on location information to deliver location-based QoS to a group of UEs.

[0171] It is important to note that throughout this disclosure, where reference is made to ranging and / or positioning concepts, any one or a combination of the above-mentioned ranging and / or positioning methods or other ranging or positioning methods known to those skilled in the art may be used.

[0172] Section: Ranging constellations (including their configuration)

[0173] Figure 5 A block diagram of a wireless system for providing ranging and / or positioning services according to various embodiments is schematically shown.

[0174] exist Figure 5In the present invention, a ranging constellation (RC) 50 is provided, which is a group of one or more anchor UEs (A-UEs) 14 that are suitable / prepared for one or more device UEs 10 to join the group. The device UE 10 can join the ranging constellation 50, for example, to initiate a ranging process or to participate in ranging of other UEs by acting as an additional anchor UE 14. To determine the (absolute or relative) position of the UE, a single distance and / or angle generated by the ranging process may not be sufficient. In one example, the ranging constellation 50 can have at least two or more anchor UEs 14 to determine the position of the device UE by determining the distance and / or angle between the device UE 10 and the anchor UEs 14 in the ranging constellation, and using the determined distance and / or angle to calculate the position using trilateration and / or triangulation. If additional information is known or can be predetermined (e.g., certain coordinates), ranging between a device UE 10 and a single anchor UE 10 in a constellation may be sufficient to determine its relative or absolute position, regardless of whether the devices participating in the ranging are at the same altitude (e.g., a certain number of meters above sea level, on the same ground) or within the same reference plane.

[0175] The devices that make up the ranging constellation 50 may be selected based on a set of one or more selection criteria for the candidate devices, such as their support for GPS / GNSS, whether their location is known, their specific ranging capabilities, their membership in other existing ranging constellations, their distance to a particular reference point (e.g., a nearby access device), their speed, and / or a determination of whether the device is stationary or moving, or whether the candidate device is within sidelink discovery range of another device (e.g., an anchor device). The formation of the ranging constellation and the selection of its members are typically performed by a management entity, but may also be self-configured based on the selection criteria.

[0176] Device UE 10 can be added to or removed from an existing ranging constellation. Similarly, anchor UE 14 can be added to or removed from an existing ranging constellation. The ranging constellation 50 can be assigned an identity (e.g., by a management entity), and this identity can be sent to each device that joins / composes the ranging constellation 50. This identity can also be used during discovery of ranging-capable devices and / or during connection establishment and / or message exchange between ranging-capable devices to initiate ranging sessions. A ranging constellation can be assigned multiple identities (e.g., both a unique constellation instance identifier and a constellation type identifier).

[0177] Note that adding, removing, and joining a device UE 10 to a ranging constellation does not necessarily mean that the device UE 10 needs to have information about all anchor UEs in the ranging constellation, nor does it mean that sessions need to be established with all anchor UEs in the ranging constellation. For example, a group of other UEs in the ranging constellation may only be known to the LMF or other management entity. UEs in a ranging constellation can form a trusted group / domain, whereby UEs that are part of the ranging constellation can share the same / similar group / domain credentials or authorization tokens. If a UE can provide proof of possession of the group / domain credentials or authorization tokens (e.g., by sending a correct response to an authentication / authorization request or sending a correctly signed token / message), the UE can use these group / domain credentials or authorization tokens (if necessary) to prove to other UEs in the ranging constellation that it is part of the same ranging constellation. The shared group / domain credentials can be used to protect (e.g., encrypt and / or integrity protect) messages exchanged between UEs that are part of the ranging constellation. This can include protecting multicast / groupcast messages. UEs that do not possess the group / domain credentials cannot decrypt these messages. In this way, the UE does not need to directly know which other UEs are part of the constellation or may join the constellation. Alternatively or additionally, a UE in the ranging constellation may be provided with individual credentials for each other UE in the ranging constellation.

[0178] The device UE 10 corresponds to a wireless device (also referred to as a target UE) that requires ranging and / or positioning services. It should be noted that in the description of the following embodiments, the terms "device UE" and "UE" can be used interchangeably and are intended to refer to the same device. In addition, the terms position and positioning can be used interchangeably and can be relative (e.g., coordinates in a reference plane) or absolute (e.g., geographic coordinates).

[0179] Each anchor UE 14 corresponds to a wireless device that provides ranging and / or positioning signals to the UE 10. In addition, the anchor UE 14 may provide ranging / positioning services to the UE and other anchor UEs.

[0180] It should be noted that the device UE 10 and anchor UE 14 can be mobile phones or any other type of connected device and can support the Uu and PC5 3GPP interfaces. These devices may be capable of supporting a variety of radio access technologies, including but not limited to 2G / 3G / 4G / 5G networks described by 3GPP, and non-3GPP wireless technologies operating in unlicensed wireless spectrum (such as Wi-Fi, Bluetooth, and ISM bands). The mobility of the device UE 10 and anchor UE 14 does not affect the ability of the device UE 10 to become the anchor UE 14 or vice versa. Depending on the application, the anchor UE 14 can also be a fixed device (e.g., a smart TV), and the mobile device UE 10 (e.g., a mobile phone) can even be authorized to become the anchor UE 14, whether it is moving or when it becomes fixed and remains fixed in one location. Typically, the anchor UE 14 knows its location or is able to obtain its location from a location service, or is able to use ranging procedures with the device UE 10 to provide / determine a reference plane and reference direction for distance / angle measurements, and should be able to do so even when out of network coverage. Preferably, the anchor UE is within the coverage of the network so that it can access the location service provided by the core network, can obtain its location, can keep synchronization with the network, can obtain authorization for ranging procedures, etc.

[0181] Both the device UE 10 and the anchor UE 14 may have a receiver unit for receiving ranging reference signals and / or other wireless signals for distance / angle measurements, and may be capable of determining the timing of these signals, and a computing unit for calculating / determining distance / angle / positioning measurements (e.g., reference signal time difference (RSTD), reference signal received power (RSRP), Rx-Tx time difference between the device UE 10 and the anchor UE 14 and / or between the device UE 10 and the radio access device (e.g., base station or gNB) 20). The computing unit (or another computing unit at the device UE 10 or anchor UE 14) may also be capable of calculating the distance, angle, or (relative) position based on these distance / angle / positioning measurements received from other devices (possibly enhanced with data from other sensors (such as an air pressure sensor)) and / or the distance / angle / positioning measurements (possibly enhanced with data from other sensors (such as a magnetic sensor)). In addition, the device UE 10 and the anchor UE 14 may have a transmitter unit for transmitting signals used for distance / angle measurement (e.g., a location reference signal or a sounding reference signal) and may be able to determine the timing of these signals. The anchor UE may have a known / fixed location and may therefore be a location reference unit as described in 3GPP document R2-2109489, and may also transmit this information to the device UE 10 and / or other anchor UEs 14. The device UE 10 and the anchor UE 14 may support transmission and reception of signals to enable communication with a wireless access device (e.g., as defined in 3GPP specification TS 38.300), and may be capable of communicating with a (cellular) core network and its services (e.g., as defined in 3GPP specification TS 23.501) using protocols such as the LTE Positioning Protocol (LPP) defined in 3GPP specification TS 36.355 or the NR Positioning Protocol A (NRPPa) defined in 3GPP specification TS 38.455, such as location services (e.g., as defined in 3GPP specification TS 23.273). In addition, the device UE 10 and the anchor UE 14 may support discovery and communication with another device UE and / or an anchor UE via PC5 / sidelink (e.g., as defined in 3GPP specifications TS 38.300, TS 23.287, TS 23.304, and TR 37.985).

[0182] The device UE 10 , the anchor UE 14 and the wireless access device 20 may together form a positioning constellation (PC) 60 .

[0183] Depending on the application and accuracy requirements, ranging-based or sidelink-based positioning can be performed between the device UE 10 and one or more anchor UEs 14. For example, a single anchor UE 14 can use a simple application such as coarse ranging to provide an indication of a rough distance / area. Other applications may require three or more anchor UEs 14 that are tightly clock-synchronized with the device UE 10.

[0184] The ranging constellation 50 includes a set of UEs, such as the device UE 10 and at least one anchor UE 14, that perform ranging and can support each other in determining geographic location and / or providing relative positioning services (e.g., determining position in a reference coordinate system). In the ranging constellation 50, one of the anchor UEs 14 may be a head or leading anchor UE responsible for managing the remaining set of anchor UEs 14 (e.g., serving as a synchronization source for the other anchor UEs). In addition, the anchor UE may be configured to support a management entity to, for example, select, configure, reconfigure, etc., the other anchor UEs 14.

[0185] At least one wireless access device 20 (e.g., a base station or gNB) is configured to handle the connection of the UE to the core network (CN) 30. It can also support multiple positioning technologies in an isolated manner or in combination with other wireless access devices 20. The wireless access device 20 is responsible for radio resource allocation and scheduling, clock time synchronization, and power control for connected devices.

[0186] The wireless access device 20 may also provide positioning signals and may provide (access to) positioning services for devices in the ranging constellation 50. The positioning constellation 60 includes a set of at least one wireless access device 20 (possibly in conjunction with positioning services in the core network, such as LMF), which provide positioning services to at least one device UE 10 or anchor UE 14. The device UE 10 or anchor UE 14 may not always be connected to the wireless access device 20, i.e., they may be out of coverage, but the device UE 10 or anchor UE 14 may have previously connected to a positioning service associated with the positioning constellation 60 to obtain its location; it may also have received this location from a management entity (e.g., an installer UE). Later, when the anchor UE is out of coverage, it may still send ranging signals and / or information about its location while not connected to the wireless access device 20.

[0187] In addition, the core network (CN) 30 provides a networking function that controls the access network and manages the UE devices 10 and anchor UE 14 that subscribe to core network services and are served by the access network. For example, it can be a 5G core network. The core network 30 may include multiple network functions, including an access and mobility management function (AMF) 32 configured to manage access and mobility of subscribing UEs, a location management function (LMF) 34 configured to manage positioning services provided to the UE 10 and the anchor UE 14, a ranging management function (RMF) 36 configured to manage ranging services between the (ranging) UE 10 and the anchor UE 14, and a network exposure function (NEF) 38 that allows the application function (AF) 40 to connect to the core network 30.

[0188] It should be noted that in the described embodiments, a network controller device may perform the role of the core network 30. It should also be noted that the LMF 34 or RMF 36 may include or be connected to a set of services / functions (e.g., a Gateway Mobile Location Center (GMLC)) that may be collectively responsible for / capable of determining, verifying, providing, and / or storing a set of locations, distances, angles, coordinates, and other related information for location and / or ranging services, and / or managing / configuring / operating a set of location and / or ranging services, and / or combining distance, angle, and location information with distance, angle, and location information from other sources or generated by various location / ranging mechanisms. The terms LMF or RMF refer to any such service / function or combination thereof. LMF and RMF are also referred to as location services, ranging services, or combined location and ranging services. Application function 40 may be a third-party application that may be interested in utilizing the services provided by the core network 30 and the wireless connectivity provided to the UE 10 and / or anchor UE 14.

[0189] According to various embodiments, a management entity is provided that configures one or more UEs as anchor UEs 14 to form a ranging constellation 50 and support ranging services, location services, and / or ranging-based positioning services (i.e., a combination of ranging and location service functionality). In addition to improving positioning and ranging accuracy, the ranging constellation 50 also helps to at least reduce power consumption of the involved UEs 10 by combining ranging and location services.

[0190] More specifically, location accuracy can be improved by utilizing simple ranging measurements (locally or centrally initiated and / or coordinated) between devices. In an example, this can be achieved by using ProSe discovery messages and / or carrier phase-based ranging / positioning techniques and / or combining ranging / positioning signals transmitted in FR1 (e.g., low / mid-band, typically up to 7.125 GHz) and FR2 frequency ranges (e.g., mmWave band, typically above 24 GHz).

[0191] The core network 30 (e.g., a network controller device) together with the wireless access device 20 (e.g., a base station or gNB) can support ranging and / or positioning services required by one or more device UEs 10 and provided by one or more anchor UEs 14 via a management entity. The management entity can generally support one or more of the following:

[0192] A user interface is provided through which a user can select and (re)configure a group of UEs to form a ranging constellation, and / or a user can manage ranging and / or location processes and / or ranging services and / or location services through the interface, such as configuring requirements and parameters for ranging processes / services and / or positioning processes / services, including but not limited to:

[0193] Which ranging / positioning method to use (e.g., RTT-based, TDOA-based, AoA / AoD-based),

[0194] Which radio access technologies are used (e.g., 3GPP LTE, 3GPP 5G NR, Wi-Fi, Bluetooth, UWB, etc.),

[0195] which frequency bands to use (including whether unlicensed / licensed spectrum will be used),

[0196] Which bandwidth to use,

[0197] minimum / maximum / default measurement duration and / or timing of ranging reference signals / measurements,

[0198] minimum / maximum / default transmit power to use,

[0199] Expected / minimum ranging accuracy,

[0200] constellation size (e.g. number of devices, identification of the devices involved, region information, maximum distance),

[0201] constellation configuration (e.g., known positions and / or initial position estimates and / or estimated distances / angles of one or more devices comprising the constellation),

[0202] Regional map,

[0203] the coordinate system to use (including which device or anchor point to use as the primary reference point / center),

[0204] Sampling frequency of ranging and positioning measurements,

[0205] Credentials to be used during discovery and / or ranging (e.g., security key identification);

[0206] Provide an intermediary / proxy configuration function by which a network entity (e.g., a location / ranging management function), an access device (e.g., a base station), or an application function (e.g., via a network exposure function) can select and (re)configure a group of UEs to form a ranging constellation, and / or by which it can remotely manage ranging and / or location procedures and / or ranging services and / or location services (e.g., configuring requirements and parameters for ranging procedures / services and / or location procedures / services, as described in the previous item). Configuration by the network entity can be done directly (e.g., via a set of messages as part of a configuration protocol) or indirectly (e.g., via a set of policies / rules that a management entity can use to decide, for example, how to determine / select an anchor UE, or, for example, how to configure parameters to perform ranging).

[0207] Ranging-related information (eg, device identity, ranging capabilities, configuration parameters for ranging) is collected from UEs in the ranging constellation and sent to a ranging or location service and / or stored in non-volatile memory.

[0208] Ranging results (e.g., distance, angle, relative or absolute coordinates) and / or ranging measurements (e.g., round-trip time) are collected from UEs in the ranging constellation and sent to a ranging or location service and / or stored in non-volatile memory.

[0209] Information about ranging devices as discovered by UEs in a ranging constellation (e.g., discovered device identities, discovered ranging capabilities) and / or ranging results (e.g., distances, angles, relative or absolute coordinates) and / or ranging measurements (e.g., round-trip time) is collected from a group of UEs, and a determination is made as to whether the group of UEs forms a valid ranging constellation.

[0210] The managing entity may be:

[0211] Functionality provided by a UE (e.g., anchor UE 14 or installer UE) by which a user can manually manage and / or a network entity (e.g., a location service communicatively coupled to the anchor UE) can remotely manage ranging constellations, ranging and / or location processes and / or ranging / location services (e.g., configuring requirements and parameters for ranging processes / services and / or location processes / services as mentioned above)

[0212] a user or application communicatively coupled to the core network 30 (e.g., a network controller device) via, for example, the network exposure function 38 and / or the location management function 34 and / or the ranging management function 36 and / or other core network functions, by which ranging constellations and / or ranging and / or location procedures / services may be managed (e.g., configuring requirements and parameters for ranging procedures / services and / or location procedures / services as mentioned above);

[0213] a selected one of the wireless access device 20 and / or the core network 30 (e.g. a network controller device or a visited core network), which may (automatically) manage the ranging constellation and / or ranging and / or location procedures for a set of UEs connected to it, and / or the ranging and location services it provides to or by a set of UEs connected to it, e.g. after being configured by a location management function 34, and / or a ranging management function 36 (e.g. operated by a home core network); or

[0214] A location management function 34 and / or a ranging management function 36 within or outside the core network 30 may manage ranging and / or location processes / services (e.g., configuring requirements and parameters for ranging processes / services and / or location processes / services and / or configuring ranging constellations) based on operator-managed default operating settings, policies, location databases, historical measurement data, artificial intelligence models, possibly in collaboration with core network functions, including, for example, network data and analysis functions (NWDAF, e.g., for determining device density, how many devices are typically registered at a certain time of day, etc.), or user data management (UDM, e.g., for subscription-related data), and / or policy control functions (PCF, e.g., for policy-related data).

[0215] The location management function 34 and / or the ranging management function 36 or other management entities may configure (the management entity of) one or more device UEs 10 and / or one or more anchor UEs 14 and / or wireless access devices 20 based on the requirements and parameters of the ranging and / or location services (e.g., those already provided through the network exposure function). This configuration may be accomplished by sending a secure message to the respective device UEs 10 and / or anchor UEs 14 and / or access devices 20 via the PCF or AMF or directly from the location management function or the ranging management function when establishing a connection with the access device or core network function (e.g., AMF or location / ranging management function), when receiving a configuration update request, and / or when receiving a request to initiate ranging and / or position estimation by one of the devices involved. To this end, the device UE 10 and / or anchor UE 14 may need to support a protocol for configuration of the ranging procedure / service (e.g., an extension to the LTE Positioning Protocol (LPP) defined in 3GPP specification TS 36.355). If one or more UEs in the ranging constellation are out of coverage or are not directly connected to or managed by the ranging / position management function, the configuration may be provided to these UEs by the UEs in coverage, forwarded to these UEs by the UEs in coverage, or provided / forwarded by a management entity (e.g., which may be supported by the (head) anchor UE and may operate out of coverage).

[0216] In one example, the LMF is used to configure a UE with ranging capability to receive static and / or dynamic configuration information. For configuration aspects that are unlikely to change for each process or may even change during the process, that is, static configuration aspects, such as the default coordinate system to be used when the device is out of coverage and / or dynamic configuration is not available or other default values ​​to be adopted, or the policy that determines the conditions for assuming a certain role (e.g., whether the device's position is stable), or the device identity and / or security credentials used during the discovery and / or ranging process, provisioning can also be performed by other core network functions (such as PCF or DDNMF).

[0217] Possible dynamically configurable parameters for ranging capable UEs that need to be considered are:

[0218] o Which ranging / positioning method is used (e.g., RTT, TDOA, etc.),

[0219] o Which frequency bands and which bandwidth to use,

[0220] oSampling frequency of ranging and positioning measurements,

[0221] o Timing / period / duration of ranging and position signals and measurements,

[0222] oMinimum / maximum transmit power to use,

[0223] o the role of the device (e.g., anchor UE, target UE),

[0224] o ranging "constellation" information or ranging session related information (e.g., identity of anchor UEs working together to provide ranging / sidelink location services),

[0225] oThe coordinate system to use,

[0226] o Which device or location / ranging service or location / ranging service agent will collect the measurements and calculate the distance, angle or position.

[0227] The dynamic parameters mentioned above can change for each ranging session / procedure, or even during the procedure. Parameters can also be changed and / or configured per tracking area or per network (e.g., visiting PLMN vs. home PLMN). These dynamic parameters can be exchanged as part of a negotiation process between the device UE 10 and one or more anchor UEs 14 (e.g., during discovery, during capability exchange, or during connection establishment or initiation of a ranging session / procedure on a sidelink), whereby one UE can inform another UE of its preferred value or set of possible values ​​for one or more of these configurable parameters (e.g., based on its capabilities), after which the other UE (typically one of the anchor UEs, the head anchor UE, with / without cooperating / requesting LMF, possibly taking into account the preferences and / or capabilities of the other UE) can determine which values ​​to use for the configurable parameters and send a message to the other UE including the selected values. This can be accomplished, for example, by extending the direct communication request and related direct communication response messages with additional fields for this purpose. In addition, for some configuration parameters that may change during a ranging session / procedure (e.g., the role of the device), changes to one or more configuration parameters may be provided through message exchanges with other UEs (e.g., by extending a Direct Link Modification Request / Accept message with additional fields), based on which the session / procedure may be adjusted or terminated and / or a new negotiation process may be initiated. Similarly, when the device UE 10 or anchor UE 14 may participate in a negotiation process with the LMF (e.g., during a capability exchange or during connection establishment with the LMF), the UE may inform the LMF of its preferred and / or possible values ​​for one or more of these configurable parameters, after which the LMF may determine which values ​​to use for the configurable parameters and send a message including the selected values ​​to the UE. Additionally or alternatively, the device UE 10 or anchor UE 14 may not directly provide a list of preferred values ​​for capabilities or configuration parameters to another UE or LMF, but may instead provide an identifier through a message exchange with a core network function or database that stores such a list of preferred values ​​for capabilities and / or configuration parameters of UEs with ranging capabilities, by which the other UE or LMF can retrieve the list of preferred values ​​for capabilities and / or configuration parameters of the device UE 10 or anchor UE 14, which list may be linked to one or more identifiers of the UEs with ranging capabilities. The identifier of the device UE 10 or anchor UE 14 provided during the message exchange may be used to retrieve the corresponding capability list and / or list of preferred values ​​for configuration parameters.

[0228] Configuration of requirements and parameters may be accomplished in the form of a set of policy rules (e.g., provided via RRC or via a PCF policy container), which may define a set of conditions based on which the device may determine which configurations / methods / parameters / values ​​to apply, e.g., a condition defining a minimum measured signal strength above which ranging measurements in a particular frequency may occur.

[0229] In another example, upon configuration by the LMF or other management entity, for example, after the LMF has received information about the ranging constellation (e.g., from an external application (e.g., via the NEF), an LCS client, or other core network function, which can provide the (group / domain) credentials to be used) or has dynamically established a group of UEs forming a ranging constellation (on which the LMF, possibly in collaboration with other core network functions, can determine which (group / domain) credentials to use), the UEs in the ranging constellation can be provided with the (group / domain) credentials and / or authorization token. The LMF or other management entity can use, for example, the LPP protocol to provide the (group / domain) credentials for the ranging constellation to the target UE or anchor UE. Alternatively or additionally, the PCF can provide the (group / domain) credentials for the ranging constellation as part of the UE configuration data (e.g., during initial network configuration or using the UE configuration update procedure specified in 3GPP TS 23.502). Alternatively or additionally, the (group / domain) credentials for the ranging constellation can be stored in the USIM (e.g., during initial provisioning or (e)SIM profile download).

[0230] Furthermore, a (new / different) target UE or anchor UE may join a ranging constellation, e.g., a target UE may be temporarily associated with a ranging constellation in order to determine the position of the target UE when the LMF or other management entity determines that the target UE is in the vicinity of one or more anchor UEs in the constellation (e.g., based on tracking area or cell ID information provided during attach / registration to the network, or based on sidelink discovery information received from / by the target UE or anchor UE, or based on the last known position of the target UE) and / or when the LMF or other management entity determines that the target UE is in the vicinity of one or more anchor UEs in the constellation. This may be automatic when the target UE or anchor UE is in the same trusted group / domain as the other UEs (e.g., part of a set of identities provided by an application (e.g., via NEF), and / or belongs to the same closed access group, non-public network, (private) network slice), and / or when the target UE or anchor UE requests to perform a position estimate of the target UE, and / or when the target UE is requested to be added to the ranging constellation (e.g., by the target UE or application (e.g., via NEF)), after which the LMF or other management entity (e.g., PCF during initial network configuration) may provide the target UE or anchor UE with the (group / domain) credentials for the ranging constellation. Note that each time a UE joins or leaves a constellation, a new set of group / domain credentials may need to be determined and provided to all remaining UEs in the ranging constellation.

[0231] The provision of (group / domain) credentials for the ranging constellation may be accomplished, for example, when the target UE or anchor UE successfully attaches / registers to a given closed access group, non-public network, network slice, or trusted group / domain, the result of which may be provided by the core network function involved (e.g., AMF, AUSF, or UDM) to the LMF (or other management entity), and / or the LMF (or other management entity) may issue a request to the UDM (or other core network function) to verify, for a given target UE identity or anchor UE identity, whether the target UE or anchor UE has accessed a given closed access group, non-public network, network slice, and / or trusted group / domain, and / or to verify by the LMF or other management entity that the target UE identity or anchor UE identity belongs to a set of UE identities (provided as part of the ranging constellation configuration information) that may also participate in the ranging constellation. To this end, the LMF (or other management entity) may provide a protected message or protected container containing information about the (group / domain) credentials to the AMF and / or gNB for transmission to the corresponding UE. This may be a separate procedure, or the AMF and / or gNB may include this protected message / container as part of its response to the corresponding UE. Alternatively or additionally, this may be part of the authorization procedure for performing ranging (as described in other embodiments). In partial coverage or out of coverage situations, the anchor UE (on behalf of the LMF (e.g., issued and protected by its own local subset of LMF functions) or as a relayed message from the LMF) may provide a protected message or protected container containing information about the (group / domain) credentials to the target UE.

[0232] In another example related to configuration of devices implementing ranging, configuration of the device UE 10 by a management entity may be accomplished by allocating security keying material and ProSe discovery information, as described in 3GPP specifications TS 33.303 and TS 33.305. In particular, a set of discovery user confidentiality keys (DUCK), discovery user integrity keys (DUIK), and / or discovery user scrambling keys (DUSK) may be allocated to implement integrity protection, scrambling protection, and / or confidentiality protection. The device UE 10 may also be provided with an identifier, such as that identifying a ranging application. These parameters may be used in combination with discovery messages to allow devices that are permitted to perform ranging on each other to discover each other. The configuration / parameters associated with the ranging constellation 50 may not be static and may change over time. In one example, the wireless access device 20 (possibly in combination with ranging and location services) may be communicatively coupled to the device UE 10 and / or the anchor UE 14. The device UE 10 may report its device capabilities and application requirements to the RMF 36 and / or LMF 34 or other management entity (e.g., via the wireless access device 20 or via another / head anchor UE that may be connected to the wireless access 20). The anchor UE 14 may report its current configuration and may report information about the current state / evolution of the members of the ranging constellation 50 (e.g., the number of devices, their identities, their capabilities, their estimated locations, their estimated speeds / mobilities, information about their battery levels / capabilities, information about their resource capacities, or information about which devices are in coverage and which devices are out of coverage) to the RMF 36 and / or LMF 34 or other management entity directly (e.g., via the wireless access device 20) or via another / head anchor UE that may operate the management entity or may be connected to the RMF 36 and / or LMF 34 or other management entity (e.g., via the wireless access device 20). The RMF 36 and / or LMF 34 or other management entity may configure the device UE 10 and / or anchor UE 14 with a policy that determines parameters for performing ranging, ranging services, and / or location services, the parameters of which may be based on the (latest) information received about the ranging constellation. For example, if information about the current state / evolution of the constellation indicates that the number of available anchor UEs in the constellation has decreased since the ranging constellation 50 was established / determined, e.g., because multiple anchor UEs have been turned off or moved too far away from other anchor UEs in the constellation, the parameters of the ranging process or ranging / location services may be adapted to reflect the new situation and may be reconfigured / updated on the various devices involved in the ranging constellation 50 and / or the device UE 10 that may use the ranging constellation 50.If it is found that an insufficient number of anchor UEs are available in a constellation (e.g., in a particular area previously identified as being covered by the ranging constellation), the constellation may be discarded, and information about the constellation and / or configuration parameters about the constellation may be removed from the device UE 10 and / or anchor UE 14, and may also be removed from the management entity.

[0233] In addition or alternatively, the network exposure function 38 can be used (e.g., by an external application) to control network-level parameters and other parameters / configuration settings required for optimal performance of ranging and location services for the intended mobile device. These parameters can be combined with configuration parameters received from the device UE 10 and / or anchor UE 14 involved and / or (other) management entity. In the event of overlapping configuration parameters with different values, a priority scheme can be applied, whereby configuration parameters received from the device UE 10 and / or anchor UE 14 and / or (other) management entity can take precedence over parameters received via the network exposure function, and vice versa. Upon detecting overlapping configuration parameters with different values, the location management function 34 and / or ranging management function 36 and / or other location / ranging services or their agents can discard measurements and / or measurement results and / or calculated distances / angles, and / or can send an error message and / or can send a message to the respective device UE 10 and / or anchor UE 14 involved to update the configuration parameters.

[0234] Similarly, if the device UE 10 and / or anchor UE 14 receives configuration parameters or desired parameter values ​​to be used that conflict with configuration parameters (e.g., a range of valid values ​​or maximum / minimum values) received from a management entity with a higher priority, it may discard the ranging request, discard the measurement / measurement result, discard the calculated distance / angle, generate an error message, request an update of the configuration parameters, or request an exception from the higher priority management entity. In the case of multiple management entities, the core network can configure policies with priority rules for different management entities. Conflict resolution can also be performed on a first-come, first-served basis, or, for example, using the configuration received from the closest anchor UE.

[0235] Chapter: Ranging-based Positioning

[0236] Below, we will refer to Figure 5 The network architecture of FIG3 is described in more detail for specific ranging-based positioning.

[0237] According to various embodiments, ranging or positioning may be performed between the device UE 10 and the anchor UE 14 based on configuration parameters of a management entity in the anchor UE 14 or a management entity that may provide the configuration parameters via the anchor UE 14. To this end, the anchor UE 14 or the management entity may expose the configuration parameters to the one or more device UEs 10 and / or one or more other anchor UEs 14, for example, via a ProSe discovery message and / or by sending the configuration parameters after establishing a sidelink / PC5 connection with the one or more device UEs 10 and / or one or more other anchor UEs (e.g., via a PC5 signaling message or an RRC message or a direct communication request / accept message, or via an LPP / NRPPa protocol message, whereby these messages may be new messages or existing messages with additional / different fields designated for ranging purposes), and / or the anchor UE or the management entity selects and / or decides one or more of the values ​​for the parameters to perform a ranging procedure (e.g., ranging method used, bandwidth / frequency used, number of antennas used) for the ranging or location service. According to some embodiments, the ranging service or positioning service may be performed by the wireless access device 20 or by the core network 30 (e.g., a network controller device) or by a proxy through the anchor UE 14. The device UE 10 and / or the anchor UE 14 participating in ranging / positioning may send their selections and / or configuration parameters for performing ranging (e.g., ranging method used, bandwidth / frequency used, number of antennas used) (in addition to or separately from the corresponding distance / angle measurement) to the ranging service (or its proxy) or location service (or its proxy) or a management entity (which may collect information from multiple participating UEs and send it to the ranging or location service). The ranging service or location service may use this information to determine how to calculate the position / distance / angle estimate and / or determine an accuracy estimate for the measurement, a threshold for accepting the measurement, a value for compensation for measurement / calculation errors, and / or determine changes to the configuration of one or more UEs involved.

[0238] According to some embodiments, to initiate ranging, the device UE 10 may signal the anchor UE 14, or the anchor UE 14 may signal the device UE 10, or in the case of a ranging constellation consisting of more than two UEs, the device UE 10 or the anchor UE 14 may signal another device UE 10 and / or another anchor UE in the ranging constellation to request the start of a ranging session. This may be a separate signal or message, or may be indicated, for example, by setting an attribute during connection setup between the two UEs (e.g., a Boolean "rangingrequest" attribute as part of a direct communication request message or an RRCSetupRequest). This is typically done during or after a discovery phase, through which it can find out configuration parameters (as described above) and / or possible other properties of ranging services or location services provided by other devices (e.g., ranging capabilities supported, whether it acts as an anchor UE, which (preferred) ranging method to use, location information, device identifier, ranging constellation identity / identifier, list of anchor UE identities (of a ranging constellation), location information of one or more anchor UEs (of a ranging constellation), key identifier, credentials (e.g., public key), random number, location information (e.g., its geographical / GPS coordinates), signal type (supported), frequency / band information, which PLMN it supports or can connect to, which location service or location service capability it supports or can connect to, which ranging service or ranging service capability it supports or can connect to, synchronization / clock / timing information, whether it is in or out of coverage of an access device (and if in coverage which access device and its properties), whether it supports ProSe relay or other ProSe or V2X or sidelink / D2D services, antenna information / configuration). Note that the above parameters may also be transmitted (e.g., received from the PCF as part of policy information when the UE is in coverage) during the (pre-)configuration phase or after discovery (e.g., after a PC5 / sidelink connection has been established) (e.g., via PC5 signaling or RRC messages). It should also be noted that if one of the multiple anchor UEs in the ranging constellation receives a request to initiate a ranging session, the anchor UE receiving the request may forward the request or issue a request to other anchor UEs in the ranging constellation, or may forward the request or issue a request to a ranging service or location service (which in turn may forward or issue a request to other anchor UEs in the ranging constellation).

[0239] In one example, multiple anchor UEs 14 can work together to perform sidelink positioning of the target UE 10 in various coverage scenarios. The target UE can connect to multiple anchor UEs to perform the ranging procedure. By collecting information from the various ranging measurements, the sidelink position can be calculated more accurately than when using only a single anchor UE. These multiple anchor UEs can form a so-called ranging "constellation", whereby these anchor UEs can have a fixed position and can together cover a specific area, such as a room or building. The target UE can discover multiple anchor UEs, or can discover a constellation of anchor UEs (which can have their own identifiers) in its vicinity and invite them all to participate in the same ranging session / procedure. Alternatively, the target UE can discover one anchor UE (of the ranging "constellation"), after which the anchor UE or LMF (or other management entity) will invite the other anchor UEs to join the ranging session / procedure. To this end, information about session identifiers or constellation identifiers can be exchanged among the target UEs and anchor UEs involved. Additionally or alternatively, the target UE may discover an anchor UE, which may provide the target UE with a list of identities (e.g., L2 identities or L2 groupcast / multicast / broadcast identifiers used for discovery or direct communication requests (DCRs)) of other nearby anchor UEs (e.g., discovered by the anchor UE) in its discovery response message (or in a PC5 groupcast / multicast / broadcast message, or via a PC5 unicast link between the target UE and the anchor UE, e.g., using extended encapsulation LPP assistance or similar commands) and possibly other information about the other nearby anchor UEs (e.g., as part of a metadata field in a discovery message from the anchor UE to the target UE), whereby the list may be subset to include only the anchor UEs in the ranging constellation, so that the target UE performs target discovery (e.g., by including the identifiers of the anchor UEs to be discovered in its discovery request message) and / or may directly issue a DCR message to connect to these anchor UEs without first discovering them. Additionally or alternatively, the LMF (or other management entity) may request one or more anchor UEs 14 to perform discovery of the target UE 10, after which they may establish ranging connections with each other and may join a ranging session / procedure.

[0240] In one example, the LMF (or other management entity) instructs each invited anchor UE to use the same session identifier or constellation identifier by including the same session identifier or constellation identifier when establishing a connection or sending a message to initiate ranging with the target UE 10. In another example, the target UE 10 uses the information received about the constellation to derive a single session identifier or constellation identifier itself and includes this identifier when establishing a connection or sending a message to initiate ranging to each anchor UE it has discovered that matches the identity of an anchor UE in the constellation or that has provided a constellation identifier matching the constellation identifier through its discovery advertisement or discovery response. The anchor UE 14 can provide a session identifier through its discovery advertisement or discovery response (e.g., provided by the LMF or other management entity as part of its invitation to join the ranging session procedure or as part of the anchor UE's configuration information) that the target UE 10 can compare with its known session identifiers. If the session identifier matches a known session identifier, the target UE 10 may identify the discovered anchor UE 14 as an additional anchor UE that may be part of the constellation and therefore establish a connection with the anchor UE to join the ranging session with the session identifier or send a message to initiate ranging with the session identifier.

[0241] In another example, an anchor UE in a ranging constellation is configured / invited to participate in ranging and / or position estimation of a target UE, but does not need to actively establish a ranging session with the target UE. This can be accomplished by the LMF 34 or RMF 36 (or other management entity) providing configuration information to the corresponding anchor UE in the ranging constellation. The configuration information may include information about the PRS / SRS or other ranging reference signals to be used by the target UE or other anchor UE (e.g., signal characteristics / type, resource scheduling, used frequency band / bandwidth, etc.). If it receives relevant signals (e.g., determines the time of their arrival at the corresponding anchor UE) and reports these measurements (or calculated ranging results, such as distance or angle) to the LMF 34 or RMF 36 or its agent, this information can be used to monitor the relevant signals and perform measurements on these relevant signals. The configuration information provided to the corresponding anchor UE may include an identifier of the target UE or other anchor UE, or an identifier related to the ranging reference signal configuration or configuration item therein (e.g., a specific resource schedule). The anchor UE can use this identifier when reporting measurement / ranging results to the LMF 34 or RMF 36, or their proxy, by associating the specific reception of the relevant signal with the identifier. The timing of the measurement or signal characteristics or frequency used may be sufficient information for the anchor UE to determine, based on the configuration information, which ranging process or other UE the measurement applies to, so that it can determine which identifier to use in its report. The configuration information may also include information about PRS / SRS or other ranging reference signals (e.g., signal characteristics / type, resource schedule, frequency band / bandwidth used, etc.), which the corresponding anchor UE should use to transmit these ranging reference signals. The target UE may be configured by the LMF 34 or RMF 36, or other similarly configured management entity, to receive these signals, but may not be configured with information about which anchor UE will actually transmit these signals. Instead, the target UE may be configured with an identifier associated with the ranging reference signal configuration or configuration item (e.g., a specific resource schedule) therein. The target UE can use this identifier when reporting measurement / ranging results to the LMF 34 or RMF 36, or their proxy, by associating the specific reception of the relevant signal with the identifier. The timing of the measurement or signal characteristics or frequency used may be sufficient information for the target UE to determine, based on the configuration information, which ranging process or other UE the measurement applies to, so that it can determine which identifier to use in its report. The configuration information may also include relevant security credentials to enable decryption or encryption of the payload of certain signals. Since the target UE may not even need to know that another anchor UE is participating in the ranging and / or position estimation of the target UE, the LMF 34 or RMF 36, or their proxy, must ensure that the anchor UE is authorized to participate in the ranging of the target UE and / or that the target UE has consented to this.As described in other embodiments, the target UE may consent to a single anchor UE participating in the ranging of the target UE, or provide consent to all anchor UEs in the constellation at once. The LMF 34 or RMF 36, or their agents, must verify the consent of the anchor UEs and ensure that the anchor UEs are properly authenticated and / or authorized, thereby providing configuration information to the corresponding anchor UEs, including information about the PRS / SRS or other ranging reference signals to be used by the target UE or other anchor UEs.

[0242] In yet another example, a target UE discovers multiple anchor UEs, establishes connections, and initiates ranging sessions with each anchor UE using separate session identifiers. The target UE (directly if in coverage, or via an anchor UE that can forward messages or issue corresponding messages if out of coverage) can report these session identifiers and / or a set of anchor UE identifiers with which it has performed ranging and / or ranging measurements or results to the LMF 34 or RMF 36 or their agents. Based on the anchor UE identifiers, the LMF 34 or RMF 36 or their agents determine, for each identifier, whether the identifier corresponds to an anchor UE identifier in one or more ranging constellations. In this way, the LMF 34 or RMF 36 or their agents can determine whether all anchor UEs in the ranging constellation have been discovered by the target UE and / or whether the target UE has performed ranging with them. If not, the LMF 34 or RMF 36 or their agents can instruct the target UE to discover and / or connect to the remaining anchor UEs in the constellation and / or can configure and / or invite the remaining anchor UEs to discover and / or perform ranging with the target UE.

[0243] According to some embodiments, before a ranging session begins (e.g., during discovery) or during a ranging session, the target UE 10 receives an identity of each anchor UE 40. If the identity matches one of the anchor UE identities in one or more ranging constellations in ranging constellation information that the target UE may have received (e.g., from a management entity during (pre-)configuration), the target UE may check whether it has discovered all anchor UEs in the corresponding constellation and / or whether it has connected to all anchor UEs in the corresponding constellation to perform ranging. If not, the target UE may initiate discovery or connection establishment with the remaining anchor UEs in the corresponding constellation that the target UE has not yet discovered or performed ranging with. If the remaining anchor UEs cannot be discovered or cannot be connected, the anchor UEs may be out of range of the target UE (i.e., too far away from the target UE). This information (i.e., the anchor UE is out of range) together with the area information of the constellation and / or the position information of the anchor UE can be used in calculations to determine the location of the target UE, because, for example, by excluding a circular or elliptical or hyperbolic area / volume around the anchor UE, where the radius, semi-minor axis, focal length minus semi-major axis of the anchor UE are equal to or less than the (expected / calculated) length of the radio signal range of the target UE for sidelink communication (on a given frequency), or for example by excluding the area behind a "virtual" line (or another parallel line) between two other anchor UEs from which the target UE can calculate the distance, or for example by excluding a set of circular areas centered on the target UE and with a radius of the radio signal range for sidelink (including the anchor UE (e.g., as a point on the circle) but not containing one or more other anchor UEs that the target UE has discovered and can calculate the distance to, or for example by excluding those parts of the area that are not close to anchor UEs that the target UE can discover and perform ranging with, it will rule out the case that the target UE is close to the anchor UE and must be somewhere else. Additionally or alternatively, the target UE (directly if in coverage or, if out of coverage, via an anchor UE that may forward the message or issue a corresponding message) may report to the LMF (or other management entity) the identities of the anchor UEs with which it has discovered and / or with which it has performed ranging. The LMF may determine the constellation to which the discovered anchor UE belongs based on the received identifiers. If the target UE has not reported that it has discovered or is able to discover or perform ranging with one or more other anchor UEs in such a constellation, the LMF may use this information in its calculations to determine the location of the target UE, as this will exclude the case where the target UE is close to these anchor UEs and must be elsewhere.Additionally or alternatively, the anchor UE may report to the LMF (or other management entity) that it has discovered the target UE, or that the target UE is attempting to discover the anchor UE, or that a connection is being or has been established between the target UE and the anchor UE (e.g., to perform ranging), or that it has not discovered the target UE or that the target UE has not attempted to discover or establish a connection with the target UE. The LMF may use this information in calculations to determine the location of the target UE, as it may exclude the case where the target UE is close to these anchor UEs and must be somewhere else (if the target UE has not yet been discovered or has attempted to discover the corresponding anchor UE).

[0244] As mentioned above, sidelink positioning should be applicable to various coverage scenarios. If the target UE as well as the anchor UE are within the coverage of the NG-RAN, the target UE can connect to the LMF and indicate a preference to collect measurements and calculate the position of the target UE at the target UE, or indicate a preference to let the LMF calculate the position of the target UE. In the first case, the anchor UE will provide their measurements and information about their position (or reference plane / angle information) to the target UE. The target UE needs to be authorized to receive the position of the anchor UE. In the latter case, the anchor UE provides their measurements and information about their position to the LMF. In this case, the target UE also needs to send its measurements to the LMF. The LMF can configure the target UE and anchor UE accordingly.

[0245] Similarly, in the case of partial coverage, if the target UE is out of coverage of the NG-RAN and the anchor UEs (at least one of them) are within coverage, the target UE can connect to one or more anchor UEs and indicate a preference to collect measurements and calculate the target UE's position at the target UE, or indicate a preference to have the LMF calculate the target UE's position. In the first case, the anchor UEs will provide their measurements and information about their position (or reference plane / angle information) to the target UE. The target UE needs to be authorized to receive the position of the anchor UE. In the latter case, the anchor UEs provide their measurements and information about their position to the LMF. The target UE also needs to send its measurements to the LMF, but since it is out of coverage, the anchor UE needs to forward the measurements, for example by using the ProSe UE to Network Relay function.

[0246] Alternatively, in partial coverage and out of coverage situations, the anchor UE may support a subset of the LMF functionality (i.e., act as a location service agent), for example to collect ranging measurements and calculate the position of the target UE (e.g., Figure 8As shown). The anchor UE should be able to indicate this capability to the target UE, for example during discovery, or as a response to the target UE's request / preference to have the LMF calculate the target UE's position. If the anchor UE or other UEs (e.g. target UEs outside the constellation or external UEs) support a subset of the LMF's functionality, this support can be indicated as support for the SL positioning server UE / role. If the target UE agrees, the target UE can send its measurements to the corresponding anchor UE / SL positioning server UE. If multiple anchor UEs / SL positioning server UEs participate in sidelink positioning, one of the anchor UEs / SL positioning server UEs is selected, and the other anchor UEs need to send their measurements and positions to the selected anchor UE / SL positioning server UE. The anchor UE / SL positioning server UE needs to be authorized to receive the measurements of the target UE as well as the measurements and positions of the other anchor UEs, and to calculate the position of the target UE. In order to use as many measurements as possible to calculate the position of the target UE, it is important that an anchor UE / SL positioning server UE that supports a subset of the LMF functionality (e.g., the ability to calculate position) is within coverage or can be connected to other anchor UEs (e.g., other anchor UEs in the ranging constellation) as well as to the target UE, either directly (e.g., via PC5) or indirectly (e.g., via a base station or core network via Uu, or via a relay device via PC5). Therefore, the anchor UE / SL positioning server UE can indicate during discovery (e.g., in a message field during Model A / B discovery) how many other anchor UEs it is connected to or can be connected to. It can also indicate connection quality / speed / latency indicators, such as signal quality, error rate, number of hops, minimum / average / maximum delay, congestion rate, distance, line-of-sight connectivity between UEs (or the absence of, e.g., detected obstacles). The target UE can use this as selection criteria for selecting an anchor UE. The anchor UE / SL positioning server UE may also indicate whether it has a stable connection to the base station / core network (e.g., good signal quality, the anchor UE is not moving at the moment), and may indicate that it expects or has calculated (e.g., through signal analysis or other sensors) that it has a line-of-sight connection with the target UE. Additionally or alternatively, in the case of partial coverage, the anchor UE may use one or more of the above indicators (as discovered from another one or more anchor UEs) and other information about the other anchor UEs (e.g., as discovered or provided during connection establishment), such as their ability to: negotiate with the other anchor UE which of the anchor UEs needs to act as the head anchor UE, which anchor UE calculates the position of the target UE, which anchor UE advertises that it supports a subset of the LMF's functionality, and / or which anchor UE is connected to the LMF.Additionally or alternatively, an anchor UE may use one or more of the above indicators (as discovered from another anchor UE or UEs) and other information about other anchor UEs (e.g., as discovered or provided during connection establishment), such as their capabilities to determine whether to act as a head anchor UE, whether to calculate the location of the target UE, whether to advertise that it supports a subset of the LMF's functionality, and whether to connect to the LMF.

[0247] After or upon receiving the signal to initiate the ranging session, the UEs involved may verify that the request comes from an authorized UE. To this end, the UEs may need to exchange credentials, may perform authentication and / or authorization independently or supported by the core network, for example, may contact the core network to authenticate the UEs involved and verify their authorization. Once authorization is successful, one or more UEs may start sending ranging reference signals (e.g., location reference signals / sounding reference signals or other signals (e.g., ProSe discovery messages)), possibly using radio spectrum resources used for sidelink communication or sidelink discovery. This may be a repeated signal, continuing a configured number of times (e.g., with a certain pause / quiet interval between signals), or until a signal to stop the ranging session is received. The (required) timing of these signals (e.g., the start time of the first signal) may depend on or determine configured timing / delay, transmission / reception of synchronization signals, sensing of quiet periods, QoS or Quality of Experience (QoE) information (e.g., for ranging / location services or other services), scheduling resources (e.g., semi-persistent resources), DRX / sleep information that may be configured and / or exchanged between devices, timing randomization functions, signal quality measurements, measured Doppler shift / coherence time / lag of the signal, speed of the device, etc.). The device UE and / or anchor UE 14 performs ranging measurements on the received ranging reference signals (e.g., determines the time of arrival of the ranging reference signals, measures the angle of arrival of the ranging reference signals), and may calculate the distance or angle based on the techniques described above or in other embodiments.

[0248] In accordance with some embodiments, a signal to initiate a ranging session may be sent by an access device or a core network function (such as the location management function 34 and / or the ranging management function 36) to the one or more UEs involved. In one example, the access device and / or the core network function may know that two UEs are in proximity (e.g., because they are both connected to the same access device) so that the access device or the core network function may instruct the two UEs to initiate a ranging session without the UEs having to perform a discovery phase. The access device or the core network function may provide the necessary configuration parameters so that each UE knows exactly how to perform the ranging session (e.g., which frequency band or bandwidth to use, which mechanism, which type of signal, (temporary) device or ranging / session identifier and / or credentials to use during ranging, etc.), and it may also indicate the exact timing at which each UE should send the signal and the order in which the signals should be sent.

[0249] Note that any embodiments describing a device UE 10 discovering and / or performing a ranging session with an anchor device UE 14 may equivalently be replaced with two devices UE 10 discovering and / or performing a ranging session with each other.

[0250] Section: Switching to a local location / ranging service agent

[0251] According to some embodiments, the device UE 10 may determine (when and how) to obtain its position coordinates from a location service or from a ranging service based on ranging measurements, wherein one or more UEs in the ranging constellation 50 may act as a proxy for a location service and / or ranging service, for example in a given geographical area, for example by supporting similar protocols (e.g. LPP or NRPPa) and functionalities provided by the location service or ranging service (e.g. determining distance / angle / position based on position / ranging measurements, providing position / coordinates in a reference coordinate system based on a set of distances and / or angles and / or other relevant position information). A UE acting as a proxy for a location service and / or ranging service may be referred to as a SL positioning server UE. The device UE 10 may automatically turn off its use of the location services provided by the core network / access device (terminate its connection to the LMF 34) if it discovers that the ranging constellation 50 of a ranging-capable anchor UE 14 is providing location coordinates, operating a location / ranging service and / or acting as a proxy for a nearby location / ranging service, and / or if it determines that the signal coverage of access devices in a given geographical area is poor (which would prevent proper / effective use of the location services itself), and / or if it enters a certain tracking area or approaches a specific access device, and / or if it meets a set of conditions defined by a preconfigured policy (e.g., if it can discover a certain minimum number of anchor UEs), and / or may turn off its use of the location services provided by the core network / access device if it receives an explicit signal from an anchor UE, location / ranging service or management entity.

[0252] Figure 8 An example conceptual architecture according to various embodiments is shown, whereby one or more anchor UEs can act as proxies for location / ranging services by supporting a subset of LMF functionality 710 (e.g., the ability to collect ranging / position measurements, calculate the location of the device UE 10 or anchor UE 14, or share location with other entities (including the device UE 10 and anchor UE 14)). The anchor UE can advertise / provide information about this ability to act as a proxy for location / ranging services to the device UE 10 via sidelink / PC5 (e.g., during discovery) 701. Furthermore, the device UE 10 can specifically provide a request / filter in its discovery request message 701 to discover only anchor UEs capable of acting as proxies for location / ranging services. If multiple anchor UEs operate together (e.g., as part of a constellation), not all anchor UEs need to support this subset of LMF functionality. Other anchor UEs can provide their measurement reports (e.g., ranging / position measurements) or distance / angle measurements to the anchor UE supporting the subset of LMF functionality 710 via sidelink / PC5 702 (e.g., via a direct connection). Similarly, the device UE 10 may need to provide its measurement reports (e.g., ranging / position measurements) or distance / angle measurements to an anchor UE that supports the LMF functional subset. The anchor UE can then calculate the location of the device UE 10 and provide it to the device UE 10 via 701. In this way, the location of the device UE 10 can be determined even when one or more anchor UEs are out of coverage of the access device 20. Figure 8In FIG, the coverage area of ​​the access device 20 is depicted as 720. An anchor UE located in the coverage area 720 of the access device 20 can still use the LMF functional subset 710 to provide a home agent, but can also turn off (a portion of) its home agent functionality and interact with the LMF in the core network, whereby it can forward messages / information from an out-of-coverage device UE 10 or anchor UE 14 to the LMF in the core network, and vice versa. To this end, it can implement (a subset of) ProSe relay functionality and / or provide gateway functionality for repackaging or converting incoming LPP messages from the AMF or from the management entity over TCP / IP into PC5 / sidelink messages (e.g., PC5 signaling messages with LPP payload), and vice versa. By acting as a gateway or ProSe relay, the anchor UE may also provide indirect communication between other core network functions, such as an authentication server function (AUSF) or a ProSe key management function, to enable the device UE 10 to exchange authentication and authorization information with the core network to verify whether the device UE 10 and / or the anchor UE 14 are authorized to participate in ranging of the device UE 10, or, for example, to forward a mobile originated location request (MO-LR) (which may include a request and / or information related to ranging, such as a discovered anchor UE or information about a ranging constellation) from the device UE 10 to the AMF / GMLC / LMF, or to forward a mobile terminated location request (MT-LR) (which may include a request and / or information related to ranging, such as information about a ranging constellation or ranging configuration information) from the AMF / GMLC / LMF to the device UE 10.

[0253] According to some embodiments, the device UE 10 can be configured by itself or by a management entity to use ranging services within a given geographic area (e.g., within a building) and to use location services outside the given geographic area (e.g., outside a building). Ranging measurements can be sent to the RMF 36 and / or LMF 34 and / or another location / ranging service or its proxy to convert the ranging measurements into geographic or relative position coordinates. The measurements can be sent by the device UE 10 and / or by an anchor UE 14 in a particular ranging constellation 50 and / or a head anchor UE in the ranging constellation 50. Ranging measurements between the device UE 10 and multiple nearby anchor UEs 14 can be sent separately or combined in a single report forwarded to the RMF 36 and / or LMF 34 or another location and / or ranging service or its proxy. To this end, the involved UEs can send their measurements and / or estimated distances / angles between themselves and one or more other UEs in the ranging constellation to the head anchor UE. If one or more anchor UEs are out of coverage, another (head) anchor UE in coverage can also act as a proxy for RMF, LMF, or other location services or ranging services. In this case, the UEs in coverage can send measurements or reports. When the entire constellation including the head anchor UE is out of coverage, the head anchor UE can act as a proxy for certain functions (e.g., a subset of functions) of the RMF and / or LMF or other location services and / or ranging services. These functions may include converting distance and / or time and / or angle measurements into position coordinates, calibrating ranging measurements, temporarily storing measurements until the communication link with the access device is restored, etc.

[0254] According to some embodiments, the device UE 10 may be configured with a list of approved constellation identifiers and / or anchor UEs 14 that it may select for ranging and / or connect to in order to initiate ranging, and may also be configured with credential information to allow secure communication setup with the device and anchor UEs 14 in the constellation, respectively. This list may be prioritized. Alternatively or additionally, the device UE 10 may be configured with policies that specify a minimum number of anchor UEs 14 that may be found within a constellation and / or in the vicinity of the device UE 10 and / or requirements on the capabilities and / or characteristics of the anchor UEs 14 (e.g., their (relative) mobility below / within certain thresholds, minimum / maximum distance from the device UE 10, signal strength thresholds, geographic area information, tracking area information, PLMN information) to determine whether the device UE 10 should turn on ranging or initiate a ranging session, or to determine which constellation / group of anchor UEs to select / connect to for ranging. The device UE 10 may also use its estimated position based on other means (eg, GPS, Wi-Fi, or dead reckoning based trajectory interpolation based on, for example, a built-in accelerometer) to determine whether ranging services should be used.

[0255] Once the device UE 10 has determined to use ranging services, it may turn on discovery of other ranging-capable UEs in its vicinity and / or may connect (directly via Uu or via a relay device) to a ranging service or location service provided by the network (e.g., provided or managed by the LMF 34 or RMF 36), which may further instruct / configure the device UE 10. Alternatively, discovery of other ranging-capable UEs may always be turned on, and the determination to use ranging may be based on information discovered from other ranging-capable UEs (e.g., whether the discovered UE is an anchor UE, or based on (discovered / configured) information about one or more ranging constellations in the area, e.g., based on a constellation identity discovered via one of the ranging-capable UEs, or the discovery of the presence of one or more UEs constellating a ranging / positioning constellation).

[0256] The UE 10 can still use other existing positioning services.

[0257] Similarly, the anchor UE 14 may be configured by a management entity or may configure itself to turn on ranging / ranging services (e.g., start sending and / or receiving discovery messages and / or initiate a ranging session) upon entering a geographic area or upon the device UE 10 entering the area. Note that each time the device UE 10 or anchor UE 14 enters a new area or approaches a new ranging constellation, it may need to request a new / fresh authorization or may have to receive a new / fresh authorization and / or obtain a new / fresh set of credentials from the core network / access device / RMF / LMF / (head) anchor UE via a Uu direct connection or a PC5 direct / indirect connection before or upon establishing a new ranging session or joining a new ranging constellation.

[0258] According to some other / independent embodiments, the device UE 10 may automatically turn on ranging services and search for nearby anchor UEs 14 and / or constellations (e.g., ranging constellations 50) with ranging capabilities when temporarily disconnected from the LMF 34 or other location services provided by the core network, such as when out of range. To this end, the device UE 10 may be configured with a policy that determines conditions for doing so, such as minimum / maximum signal strength (e.g., RSRP) or other signal quality parameters (e.g., RSRQ, number of failed connection attempts) of signals received from nearby access devices, and turns on or off its use of ranging and / or positioning services when the signal strength is below / above these parameters.

[0259] According to some embodiments, the device UE 10 may not be aware of the coverage situation of one or more anchor devices 14, or the coverage situation may have changed or is changing at the moment when a ranging operation has just been initiated or is in progress, or it may allow for not only centralized positioning (e.g., using LMF / RMF of the core network via a direct Uu connection or via a UE-to-NW relay operated by an anchor UE, for example) in coverage and partial coverage situations, but also out-of-coverage ranging operations (e.g., using a local agent of the LMF, using decentralized positioning). In these situations, the device UE 10 may perform an operating mode that is not expected or desired by the anchor device 14 or the core network, or may be different from the operating mode selected by the anchor device 14. Therefore, the device UE 10 may include a flag in a message (e.g., a direct communication request message) to one or more anchor devices 14 indicating the solution selection it has made (e.g., an out-of-coverage solution). Upon receiving the message, the one or more anchor devices 14 may need to check (based on policies received while in coverage) whether the connection environment is out of coverage (e.g., the one or more anchor devices 14 are indeed out of coverage) and whether an out-of-coverage solution is applicable, or whether a partial coverage solution is applicable (if the one or more anchor devices can connect to the core network / LMF). If the policies of the one or more anchor devices 14 determine that there is a solution mismatch, e.g., the out-of-coverage solution is not allowed at this time because the one or more anchor devices 14 are in coverage, the one or more anchor devices 14 may not respond to the message, or may send a response message including an indication that the solution requested by the device UE 10 is not allowed / accepted by the anchor device 14. In principle, the anchor UE may take one of the following alternative steps:

[0260] - Not sending a message to the device UE 10 (eg ignoring or continuing with the selected solution) or sending a message including a field indicating its coverage situation.

[0261] - Sending a message to the device UE 10 to continue using the selected solution.

[0262] - Sending a message to the device UE 10 that the selected solution is not feasible, whereby the message may include information about which different solution the device UE 10 should choose.

[0263] - Sending a message to the management entity requesting permission to proceed with the chosen solution, which can then inform the device UE 10 of the decision.

[0264] Note that the selected solution (e.g., out-of-coverage, partial coverage, or in-coverage solution) typically also determines which authorization procedure to perform and / or which security parameters to use (e.g., passwords, encryption keys). Therefore, it is important that all UEs participating in the ranging / sidelink positioning operation agree on the use of the same solution. Therefore, it is advantageous if the verification of the type of solution and parameters to be used is performed before the key establishment and authentication phase. In particular, it is advantageous if the verification of the source UE authorization (step 4 of solution #4 in TR 33.740) is performed before the direct authentication and key establishment procedure (step 3 of solution #4 in TR 33.740). This is advantageous because in this case the risk of denial of service is reduced.

[0265] It should also be noted that the solution indication in the request message sent by the device UE 10 may not be an explicit flag, but may be implicit by sending one or more parameters specific to a particular solution, e.g. if it includes an authorization token to be used during out-of-coverage operation, then it is clear to the anchor UE 14 that the device UE 10 has selected the out-of-coverage solution.

[0266] Further note that negotiation regarding the type or parameters of the solution / protocol to be used (in coverage or out of coverage) may be conducted, signaled, or verified during the initial discovery phase.

[0267] Section: Discovering and requesting use of ranging constellations

[0268] According to some embodiments, an anchor UE providing ranging services and / or location services (e.g., ranging-based positioning services or proxies thereof) may provide ProSe / V2X / D2D services to access such ranging and / or location services via a sidelink, for example, to be able to obtain / provide location information or initiate ranging. Such ProSe services may be advertised via sidelink discovery using a specific ProSe / V2X / D2D service identifier or application code, after which other UEs may establish connections to and use such services via a sidelink. The LMF 34, RMF 36, or other ranging and / or location service or other management entity may provide credentials that allow and / or may be used to protect discovery and / or message exchanges between the ranging-capable device UE 10 and the anchor UE 40.

[0269] In a further embodiment, the device UE 10 may be configured to obtain or request its location coordinates based on ranging measurements from one or more anchor UEs 14 in the ranging constellation 50. The anchor UE 14 may advertise ranging reference signals (which may be detected by nearby device UEs 10, e.g., based on their frequency, timing, signal characteristics / type, waveform, bandwidth, configured resources), or advertise ranging-based positioning (combined ranging and location service functionality) as a proximity service, or advertise support for ranging / location services and / or other ranging / location capabilities, and / or provide information about its (last known) location, or send discovery messages within a configurable time interval known to the ranging service and / or configured (e.g., by a management entity) on the UEs involved in the particular ranging constellation 50 to which the anchor UE 14 belongs. Thus, the device UE 10 can identify and check the integrity of the announcement / discovery message, can determine the arrival time of the announcement / discovery message, and can extract, for example, timing information from the message (e.g., the sending time of the announcement / discovery message included in the message, the processing time of the message as a response (e.g., t3-t2 in the case of FTM), the time between the reception of the message as a response, clock synchronization information) to calculate the distance between the device UE 10 and one or more anchor UEs 14 in the ranging constellation. In addition, the device UE 10 can calculate a restricted area that approximates its position coordinates based on one or more distances obtained, for example, from round-trip time measurements and / or flight time estimates between the device UE 10 and one or more anchor UEs 14. In addition, the device UE 10 may receive a list of authorized anchor UEs 14 in its vicinity via the RMF 36 or LMF 34 or a management entity, and upon approaching an authorized anchor UE 14 within its ranging distance, for example, after discovering such an authorized anchor UE, connecting to it, and / or requesting to use the ranging / location service or service agent provided by such an anchor UE, the device UE 10 may obtain location coordinates (e.g., calculated coordinates of the device UE 10, location coordinates of the anchor UE 14 and / or one or more access devices or location reference units) and / or an estimated relative position / distance / angle between one or more devices in the constellation from the anchor UE 14 without using the RMF 36 or LMF 34, or any other location service of the core network 30 (e.g., a network controller device). In this case, the anchor UE 14 may use the ranging procedure / service to measure the distance and / or angle between itself and the device UE 10, and convert the distance into a location coordinate based on its current location coordinate locally on the device. Alternatively, the device UE 10 may measure the distance and / or angle using a ranging procedure / service and forward it to the anchor UE 14 to request that the measured distance be converted into geographic coordinates.

[0270] According to some embodiments, the anchor UE 14 may provide its geographical coordinates to the device UE 10, which the device UE 10 may use after measuring the distance and / or angle between itself and the anchor UE 14. Transmitting the geographical coordinates of the anchor UE 14 should be done in a secure manner with respect to integrity and / or confidentiality, so the anchor UE may only provide its coordinates after a secure communication channel has been established between the device UE 10 and the anchor UE 14, and / or send the geographical coordinates protected by a key that only allows the device UE 10 or a group of authorized device UEs 10 to decrypt the information and / or allows the device UE 10 or a group of authorized device UEs 10 to verify the integrity of the information (via a message integrity code or a digital signature).

[0271] According to some embodiments, instead of sending information about the location (e.g., geographic coordinates) of the anchor UE 14 to the device UE 10 or another anchor UE, the anchor UE 14 may send an identifier (e.g., a location identifier, which may be pre-configured / assigned to the anchor UE by a location service / database or self-assigned, for example) to the device UE 10 or another anchor UE (e.g., in a discovery message, a connection establishment message, a PC5 signaling message, or a user plane message (e.g., a message on the IP layer)), possibly together with an identifier or address of the location service / database, which identifier may be used by the device UE 10 or another anchor UE that receives the identifier to retrieve the location coordinates of the anchor UE via a secure connection with a location service / database (e.g., identified by an optionally provided location / database identifier or address, or a default location service / database known to the UE or core network to which the UE is connected). To achieve this, the anchor UE (e.g., configured / authorized by its user or a management entity) or the anchor UE acting on behalf of the management entity or the management entity acting on behalf of the anchor UE may grant permission to retrieve the location of the anchor UE by performing one (or more) of the following:

[0272] - By providing the device UE 10 or the other anchor UE with authentic authorization credentials (e.g., an authorization token) that can be used to authenticate / verify authorization (i.e., provided by the connected anchor UE 14), for example, by performing an authentication procedure with the corresponding anchor UE 4, or by verifying whether the credentials match or can be securely associated with previously stored credentials of the anchor UE 14 in the device UE 10, the other anchor UE, or the LMF 34, RMF 36, or other location and / or ranging service or its proxy or other management entity, or a core network function (e.g., UDM / AUSF) to which the device UE 10 and the other anchor UE can be connected. The anchor UE can register the given consent with the specific device UE 10 or the other anchor UE, or provide a copy of the authorization credentials (e.g., authorization token) given to the device UE 10 or the other anchor UE to the LMF 34, RMF 36, or other location and / or ranging service or its proxy or other management entity, or other core network function (e.g., UDM / AUSF). The device UE 10 or the other anchor UE may include the provided authorization credential / token in a message request to the LMF 34, RMF 36 or other location and / or ranging service or its proxy or other management entity or the anchor UE 14, after which the receiving entity may verify that the authorization credential / token is authentic and, if so, provide the location of the anchor UE 14 to the device UE 10 or the other anchor UE.

[0273] - by providing an authorization message / credentials to the corresponding LMF 34, RMF 36 or other location service or ranging service or proxy thereof, or other management entity, or location database, whereby it can be verified that the message / credentials originate from the corresponding anchor UE (e.g., performing an authentication procedure with the corresponding anchor UE 14), or by verifying that the credentials match or can be securely associated with previously stored / credentials of the anchor UE 14 in the LMF 34, RMF 36 or other location and / or ranging service or proxy thereof, or other management entity or core network function (e.g., UDM / AUSF). Such an authorization message may include fields / payloads containing information about a given consent (e.g., validity period), to which UEs the consent is given (e.g., which set of identities), information about credentials or tokens that must be provided by a given UE before it can be given the location of the anchor UE). The authorization message may be sent by the anchor UE 10 when registering with the network, or when receiving a ranging request (e.g., the device UE 10 connects to the anchor UE 14 and requests to use the ranging service), or, for example, when it first connects to the LMF 34, RMF 36 or other location and / or ranging service, or its proxy or other management entity, or may be sent in response to the LMF 34, RMF 36 or other location and / or ranging service, or its proxy, or other management entity having sent a message to the anchor UE requesting permission to share its location with the device UE 10. In the case where a group / domain credential or authorization token or closed access group or NPN or (private) network slice (which is used to protect communication between UEs of the ranging constellation and / or restrict communication only between UEs belonging to the group / domain / closed access group / NNP / slice) is associated with the ranging constellation, the anchor UE may only need to provide consent once for all UEs in the ranging constellation (e.g., by including the ranging constellation ID and / or group / domain credential and / or closed access group or NPN or (private) network slice information to which the consent will be associated in a message sent by the anchor UE to the LMF 34, RMF 36 or other location and / or ranging service or its agent, or other management entity). For example, this can be done during the message exchange when the anchor UE joins the ranging constellation. The consent can also be provided by the application that manages (via the NEF) the ranging constellation and / or the UEs involved, for example, by implicitly or explicitly providing the consent in the ranging constellation configuration information that it can send to the LMF or other management entity. The consent may also be stored in the UDM or GMLC (typically in the target UE's home network), which may be verified, for example, by the AMF or other core network functions.

[0274] - This permission is granted by providing consent in its subscription (e.g. UDM) or by providing consent through the Network Exposure Function (NEF) (e.g. by the application managing the corresponding anchor UE). Note that the consent provided in the subscription or provided through the NEF can be configured per ranging constellation or per group / domain / closed access group / NNP / (private) network slice that can be associated with a ranging constellation.

[0275] According to some embodiments, the device UE 10 may calculate its position coordinates based on ranging reference signals obtained from one or more anchor UEs 14 via a sidelink channel (e.g., via a sidelink discovery message or other signal sent using sidelink resources) and the position information of the one or more anchor UEs. To this end, the device UE 10 and the one or more anchor UEs 14 may exchange messages to initiate a ranging session. One or more of these messages may include a ranging session ID (which may be used by all UEs participating in the ranging session) and / or may include a ranging constellation identifier and / or may include a ranging reference signal. The ranging reference signal may include (encoded) information about the reference signal type, UE identification information, ranging session ID, ranging constellation identifier, constellation identification information, credential information, random number, timing information, and / or distance / angle / position information.

[0276] According to some embodiments, if the device UE 10 wants to initiate ranging with two or more anchor UEs, it may indicate the number of anchor UEs and / or a set of anchor UE identifiers and / or constellation identifiers as part of a message initiating a ranging session (e.g., a direct communication request with a field indicating a request for a ranging service (using, for example, an application or service identifier defined therefor)). These messages may be sent as multicast / broadcast messages to all involved anchor UEs (in which case the anchor UEs initiate ranging with the device UE 10 and / or send corresponding configuration parameters for ranging to the device UE 10), or may be sent via a unicast message to one of the anchor UEs (e.g., the head anchor UE) (in which case the anchor UE receiving the unicast message sends corresponding messages to other anchor UEs within or nearby the constellation to invite them to become part of the ranging session and / or initiate ranging with the device UE 10 and / or send corresponding configuration parameters for ranging to them).

[0277] According to some embodiments, the position coordinates of the anchor UE 14 may be exchanged with the device UE 10 via a sidelink channel, and the calculation of the position may be done after the device UE 10 has (simultaneously) achieved clock time synchronization with these anchor UEs 14 and / or after connecting to one or more anchor UEs 14. By using time difference of arrival, round trip time, and / or time of flight measurements based on ranging reference signals, the distance between the device UE 10 and one or more anchor UEs 14 may be calculated and exchanged between the device UE 10 and one or more anchor UEs 14 (e.g., via a connection established between the device UE 10 and one or more anchor UEs). In addition, if the device UE 10 or anchor UE 14 has multiple antennas, angles may be determined. Assuming that the device UE 10 and one or more anchor UEs 14 are located in the same horizontal plane (i.e., at a similar altitude), and the distance and / or angle between the anchor UEs 14 is known or can be calculated (e.g., based on the geographic coordinates of the anchor UEs 14 and / or distance / angle measurements performed between two or more anchor UEs 14, the results of which can be shared with the device UE 10 and / or a ranging / location service), the position of the device UE 10 can be estimated based on trilateration and / or triangulation by using the distance measurements between the device UE 10 and at least two anchor UEs 14 (as well as information about the known or calculated distances and / or angles between the anchor UEs, and / or the position coordinates of the anchor UEs 14) or the distance and angle measurements between the device UE 10 and at least one anchor UE 14 (as well as information about the known or calculated distances and / or angles between the anchor UEs, and / or the position coordinates of the anchor UEs 14).

[0278] In order to handle possible height differences between UEs in the ranging constellation, the device UE 10 may need to use additional anchor UEs as additional references for distance and / or angle measurements.

[0279] Chapter: Centralized Positioning

[0280] According to various embodiments related to centralized positioning based on ranging measurements with an anchor UE node 14, the device UE 10 may approach an anchor UE 14 of a ranging constellation 50 to perform ranging measurements. Upon receiving a ranging request from the device UE 10, the anchor UE 14 may inform the device UE 10 of the ranging constellation 50 via the LMF 34, RMF 36, or other location or ranging service, or via another communication channel. The device UE 10 may store the constellation information and, whenever it is near the ranging constellation 50, it may decide based on the ranging measurements whether it wants to receive location coordinates from one or more anchor UEs 14 or other UEs in the ranging constellation 50 that may provide ranging services and / or may serve as proxies for location services. The device UE 10 and the other device UEs 10 and the anchor UE 14 may be part of a positioning constellation 60, from which the location service may (centrally) determine the location of the device UE 10. The device UE 10 may connect to the LMF 34, RMF 36, or other location or ranging services provided by the network directly through the Uu interface or via a relay connection between the device UE 10, another UE, and an access device 20 that provides access to the LMF 34, RMF 36, or other location or ranging services (e.g., exposed via a secure connection or, for example, a discovery message via a relay device) and / or receive information from the LMF 34, RMF 36, or other location or ranging services. The anchor UE 14 or the device UE 10 with ranging capability may act as a relay device for other UEs (e.g., other UEs that are part of a positioning constellation) (e.g., using a ProSe relay service). A UE that is part of a ranging or positioning constellation may be configured with specific identifiers and parameters, such as a relay service code (RSC) and / or discovery credentials, which allow other UEs that are part of the constellation and / or are nearby and / or capable of ranging and / or location services to access the LMF 34, RMF 36 or other location services and / or ranging services via a ProSe relay connection based on the specific relay service code. The LMF 34, RMF 36 or other ranging and / or location services or other management entities may provide credentials that allow and / or can be used to protect discovery and / or message exchanges between a UE 10 having ranging capabilities acting as a remote UE, a corresponding UE acting as a relay device, and a ranging / location service.

[0281] When the device UE 10 needs to obtain its location (e.g., geographic) coordinates, it can initiate a ranging request to any anchor UE 14 in the ranging constellation 50 via the ranging service and indicate its need for location coordinates. Upon receiving the request for location coordinates, (at least) one anchor UE 14 in the ranging constellation 50 can perform ranging measurements and, for example, share its ranging measurements with the RMF 36 and / or LMF 34 to obtain the geographic coordinates of the device UE 10 based on the ranging measurements between the device UE 10 and the anchor UEs 14 in the ranging constellation 50. If more than one anchor UE 14 performs ranging measurements, the ranging measurements can be combined in a single report (e.g., by a head anchor UE collecting ranging measurements from each anchor UE and sending the combined ranging measurements to the LMF 34 or RMF 36). Note that if these anchor UEs 14 explicitly participate in ranging for the device UE 10 (e.g., by participating in the same ranging session), the device UE 10 can create such a report because it can perform ranging with each anchor UE 14. The report may be sent directly to, for example, the RMF 36 and / or LMF 34, or indirectly via the (head) anchor UE 14. As previously mentioned, the anchor UE may also participate implicitly, for example by receiving information (e.g., reference signal characteristics / type, timing or resource information) from the LMF or other management entity that allows the anchor UE to monitor the ranging reference signals sent by the device UE 10, without the device UE 10 being aware of this or having to join the same ranging session.

[0282] It should be noted that the LMF 34 and / or RMF 36 can request that the anchor UE 14 provide its own known location coordinate information and / or antenna orientation information (if known) to the LMF 34 or RMF 36. The antenna orientation information can then be used by the LMF 34 and / or RMF 36 to improve ranging methods used, for example, for customized beamforming to improve the angle of arrival calculation between the anchor UE 14 and the device UE 10 for a given antenna orientation. In addition, the LMF 34 and / or RMF 36 can request the 5GS infrastructure to assess the position and orientation of the anchor UE 14. This may require, for example, the anchor UE 14 to measure PRS signals (transmitted by one or more access devices 20) and send these measurements to the LMF 34 and / or RMF 36 for position estimation. These measurements can also be used to determine the orientation of the anchor UE. For example, if an anchor UE 14 returns its beamforming settings (e.g., transmit power, direction) when performing measurements, such as reference signal time difference (RSTD) and / or reference signal received power (RSRP), with one or more different radio access devices 20 (e.g., gNBs), the 5GS infrastructure can determine the orientation of the anchor UE 14. In this case, the radio access device 20 (e.g., gNB) can perform beam scanning during initial access or broadcast of an SSB, or perform beam determination in idle mode (e.g., as described in 3GPP TS 38.802, "Study on New Radio Access Technology," V14.2.0, Section 6.1.6.1). This allows the gNB to determine the position of the anchor UE 14. Similarly, the anchor UE 14 can transmit, for example, synchronization signals (SS) in multiple directions. The radio access device can measure the received power of different synchronization signals and, based on the signals / responses received by the radio access device 20 (e.g., gNB) from the anchor UE 14 in different beam directions, combine these measurements to calculate the orientation of the anchor UE 14.

[0283] According to other embodiments related to centralized positioning, such as Figure 10As shown, the LMF 34 (or RMF 36 or other management entity) may be instructed / configured (e.g., by the GMLC 37 via the AMF 32 or by the AMF 32 directly) to monitor the locations of a set of anchor UEs (e.g., for a given set of anchor UEs in the ranging constellation 50) over a period of time based on periodic mobile terminated location requests (MT-LRs) 1001 (e.g., issued by the GMLC 37) for the corresponding set of anchor UEs. 14 or for anchor UEs in a specific area (e.g., based on area information associated with the ranging constellation 50, such as (a set of) tracking areas, (a set of) gNB / cell identifiers, (a set of coordinates)). The LMF will 1002 configure the set of anchor UEs and / or the AMF (and / or NG-RAN (not shown)) to periodically provide updated location information to the LMF and / or perform measurements 1003, and send ranging / location measurements to the LMF to enable the LMF to determine the new location of the anchor UE. The LMF may 1004 store the latest locations of all these anchor UEs in its own memory, or request another core network function (e.g., the GMLC 37 or the Unified Data Repository (UDR) 39) to store the location information of these UEs. The location information of the anchor UE may be further updated each time the anchor UE issues a Mobile Originated Location Request (MO-LR) to the network, at which time the LMF will retrieve or determine the location of the anchor UE and store the updated location information in the corresponding memory.

[0284] To determine the location of the target UE 10 using ranging / sidelink positioning, the target UE may 1005 issue a MO-LR to the network (e.g., via the Uu connection if the target UE is within coverage, or indirectly (e.g., via a ProSe UE to network relay or gateway function provided, for example, by the anchor UE or by the anchor UE itself reporting the MO-LR on behalf of the target UE (e.g., after PC5 discovery or PC5 connection establishment)), or the GMLC 37 (or other LCS client) may 1006 issue a MT-LR to the network. These location requests are typically sent to the AMF 32, which then 1007 selects the LMF 34 (or RMF 36 or other management entity) to handle this request. In case of ranging, it is important that the LMF selected for handling the location request of the target UE is the same LMF selected for handling the location request and / or position determination of the anchor UE (e.g. of the ranging constellation 50) with which the target UE will perform ranging. Otherwise, this can cause problems for the ranging and / or sidelink positioning process, since the ranging measurements / results may end up in different LMFs if the target UE and the anchor UE will be served by different LMFs. In addition, the ranging configuration and resource allocation (e.g. the timing of when to send which ranging reference signal and at which frequency) may not be aligned. To achieve this, the AMF The AMF 32 may select an LMF serving a specific area that overlaps / corresponds with area information related to the target UE (such as a Tracking Area Identifier (TAI) or a gNB / Cell ID) that it may have received (e.g., from the NG-RAN or the target UE itself, for example, as part of a location request or registration request or a separate message). This is because the target UE and the anchor UE will be communicating via PC5 / sidelink, and therefore the anchor UE and the target UE are likely to be located in the same area served by the LMF. The AMF may retrieve information about the area served by the LMF (e.g., a set of tracking areas, a set of gNB / Cell IDs, a set of coordinates representing the area it covers) from the LMF itself or, for example, from the GMLC 37 or UDR 39, which may store this information. Alternatively, the AMF 32 may select an LMF serving most other UEs in the area that overlaps / corresponds with area information related to the target UE (such as a Tracking Area Identifier (TAI) or a gNB / Cell ID) that it may have received (e.g., from the NG-RAN or the target UE itself), to increase its chances of selecting the same LMF.In case the AMF has information about the target UE and one or more anchor UEs that will participate in ranging / sidelink positioning with the target UE (e.g. based on discovery information from the target UE about which anchor UE(s) it has discovered via PC5 / sidelink, which the target UE may have provided to the AMF (e.g. as part of MO-LR or in a separate message), or e.g. by the anchor UE providing discovery information or connection setup information related to the target UE to the AMF, or e.g. by the anchor UE having information about the ranging constellation 50, or e.g. by receiving a location request (which includes not only information about the target UE but also information such as identities of one or more anchor UEs used for ranging / sidelink positioning of the target UE), or e.g. by receiving information, e.g. from the NG-RAN or the target UE or the anchor UE, that the anchor UE is used to relay messages from the target UE (e.g. by acting as a ProSe UE to network relay or gateway, e.g. when the target UE is out of coverage)), the AMF may check whether it is already serving the one or more anchor UEs and, if so, use the information about the LMF that is serving or has been selected for the one or more anchor UEs to select the same LMF for the target UE. If the AMF is not currently serving one or more of these anchor UEs, it may request the UDM (not shown) to provide information about which AMF is the serving AMF for the UE that the current AMF is not serving. The current AMF 32 may ask the serving AMF 32 (2) for that UE which LMF it has selected for that UE and then select the same LMF. Alternatively, the GMLC or UDR may store information about the serving LMF for each UE. When the target UE or anchor UE registers with it and / or issues a location request, the AMF (or LMF) may retrieve this information from the GMLC or UDR, or request the GMLC or UTR to provide this information so that the AMF can select the same LMF (or have the LMF provide the UE context of one or more anchor UEs to the serving LMF or request the UE context of one or more anchor UEs from the serving LMF).

[0285] In the event that the AMF does select a different LMF for one or more anchor UEs than the target UE, if the LMF finds that it does not have UE context information (e.g., based on ranging constellation information) for both the target UE and the one or more anchor UEs that need to be involved, then the LMF 34 may request 1008 other LMFs 34(2), if they have UE context information for one or more UEs whose UE context information is "lost" (e.g. using the NL7 reference point (as specified in TS 23.273 and may need to be extended for this purpose), and if so, request that they perform a UE context transfer of the "lost" UE context information to that LMF (or vice versa), e.g. using steps 5-10 of the LMF change procedure in clause 6.4 of TS 23.273. If all LMFs do not have UE context information available for the "lost" UE, the LMF may issue a request 1009 to the AMF to assign the "lost" UE to the same LMF. If the AMF is not already serving the "lost UE", it may 1010 verify (e.g. by requesting a UDM) whether another AMF is serving that UE and, if not, to that AMF. The UE issues a network triggered service request. Otherwise, it may align with the serving AMF of the "lost" UE to select the same LMF. Additionally or alternatively, the different LMFs selected for the two or more UEs participating in ranging may 1011 coordinate with each other before or during the ranging process, for example by exchanging ranging configuration parameters, synchronizing their clocks, exchanging scheduling / resource information, exchanging security credentials, etc. This can be done by extending the NL7 reference point. The LMFs may even be located in different core networks, for example to implement inter-PLMN ranging, whereby the two or more UEs performing ranging may be served by different core networks and therefore by different AMFs and LMFs. The AMF, LMF or other core network functions may determine the LMF status based on the identity of the anchor UE or target UE found on PC5 / sidelink (e.g. SUCI, User Information ID, PRUK The LMF may determine that this has occurred by using the PLMN ID, NID, CAG or NCGI information that may have been provided by the target UE or anchor UE to its AMF, LMF or other core network function, which may have been provided during discovery on PC5 / sidelink or during / after PC5 connection establishment. To this end, the LMF may establish a connection with an LMF in the other core network, for example via a service-based interface (if the two networks are closely cooperating), or for example via a tunnel, relay or proxy connection through a GMLC that communicates with the GMLC of the other core network or establishes such a connection through the NEF of the other core network.In the case of roaming of a target UE or anchor UE, the corresponding UE is typically served by the AMF and LMF of the serving (i.e., visited) network, so the AMF can select the same LMF in the same way as mentioned above.

[0286] Once the same LMF has been selected for the target UE and the anchor UEs to be involved, or the LMFs have coordinated their configurations, the LMFs may configure the target UE and anchor UEs 1012 to enable ranging to be performed between the target UE and one or more anchor UEs (and possibly between the anchor UEs themselves). Configuration information may include session or ranging constellation identifiers, e.g., for initiating a joint ranging session or for reporting corresponding ranging measurements or ranging results to the LMF, but ranging may also be performed "session-less," in which case the timing of the measurement or the signal characteristics or frequencies used may be sufficient information for the target UE or anchor UE to determine which ranging procedure or other UE the measurement applies to. To this end, the configuration information provided to the corresponding target UE or anchor UE may include an identifier of the target UE or other anchor UE, or an identifier associated with a ranging reference signal configuration or configuration item therein (e.g., a specific resource scheduling), as described in other embodiments.

[0287] Note that in the case where the ranging constellation is associated with a set of group / domain credentials or authorization tokens, the target UE and / or anchor UE of the ranging constellation may need to provide proof of possession of the group / domain credentials or authorization tokens (e.g. by sending a correct response to an authentication / authorization request or sending a correctly signed token / message) when the target UE and / or anchor UE registers with the core network (typically with an AMF), preferably before the AMF selects the LMF, for example as part of the main authentication procedure or as a separate procedure with the AMF and / or AUSF / UDM. If the AMF does not have this information, the AMF may request the LMF or GMLC or UDR or UDM, which may have stored this information as part of the ranging constellation information, to provide this information, or the LMF may perform such a request or ask the AMF or AUSF / UDM to perform such a check. Similarly, if the ranging constellation information includes information about a closed access group identifier (e.g., operated by a non-public network) or a non-public network identifier or a (private) network slice identifier that the anchor UE or target UE needs to subscribe to or have access to in order to (temporarily) join the ranging constellation (e.g., participate in ranging for the target UE), then the AMF preferably needs to check that the target UE or anchor UE has access to the closed access group, NPN, or network slice before it selects an LMF (e.g., when the target UE or anchor UE registers with the AMF). Furthermore, if the AMF does not have this information, the AMF may request the LMF or GMLC or UDR or UDM, which may have stored this information as part of the ranging constellation information, to provide this information, or the LMF may perform such a request or request the AMF or AUSF / UDM to perform such a check. Alternatively, or in addition, the AMF may provide the necessary information (e.g., CAG ID, NPN ID, network slice ID of each UE) to the LMF so that the LMF can perform this check. Similarly, if the ranging constellation information includes information about a group of target UEs that can be served by the ranging constellation and can therefore, for example, (temporarily) join a ranging constellation indicated by, for example, a set of target user identities and / or a set of network identities (e.g. PLMN IDs), which indicates to which home network the target user needs to subscribe / belong in order to be allowed to be served by the ranging constellation (i.e. whether ranging of the anchor UE using the ranging constellation can be performed for a visiting / roaming target UE that subscribes to / belongs to a different PLMN than the serving network of one or more anchor UEs of the ranging constellation), the AMF preferably needs to check that the target UE identity is indeed in the list of target UE identities and / or the network identity (e.g. HPLMN ID) to which the target UE belongs / subscribes to is in the indicated list of network identities before it selects an LMF for that UE (e.g. when the target user registers with the AMF).If the AMF does not have this information, the AMF may request the LMF or GMLC or UDR or UDM to provide this information. The LMF or GMLC or UDR may have stored this information about a set of target UE identities and / or a set of network identities as part of the ranging constellation information, or the LMF may perform this request or ask the AMF or AUSF / UDM to perform such a check. Alternatively or additionally, the AMF may provide the necessary information (e.g., identities such as SUPI, and / or home network identities (e.g., HPLMN ID) of each UE) to the LMF so that the LMF can perform this check. Similarly, if the ranging constellation information may include a set of network identifiers (e.g., PLMN IDs) indicating which home network the anchor UE needs to subscribe to / belong to in order to be allowed to operate in the ranging constellation in the visited network (i.e., if the anchor UE is roaming / visiting a network different from its home network), the AMF preferably needs to check (e.g., when the anchor UE registers with the AMF) that the network identifiers to which the anchor UE belongs / subscribes (e.g., HPLMN IDs) are in the indicated list of network identifiers before selecting an LMF for the UE. If the AMF does not have this information, the AMF may request the LMF or GMLC or UDR or UDM to provide this information. The LMF or GMLC or UDR may already store this information about the set of network identifiers as part of the ranging constellation information, or the LMF may perform such a request or ask the AMF or AUSF / UDM to perform such a check. Alternatively, or in addition, the AMF may provide the necessary information (e.g., identifiers, such as SUPI, and / or the home network identifiers (e.g., HPLMN IDs) of the respective UE) to the LMF so that the LMF can perform this check.

[0288] Chapter: Detailed Architecture and Process of Decentralized Positioning

[0289] Figure 6 A network architecture according to various embodiments is schematically shown, wherein a mobile terminal (e.g., device UE) 10 approaches a ranging constellation 50 of a mobile terminal (e.g., anchor UE) 14 to obtain assistance from a ranging service (RS) of location coordinates obtained from a location service (LS).

[0290] According to some embodiments related to decentralized positioning based on ranging measurements with anchor UEs 14, one of the anchor UEs 14 may receive a request for location (e.g., geographic) coordinates from the device UE 10, either directly or via another device UE near the ranging constellation 50, and may confirm the request. Ranging measurements corresponding to the device UE 10 and the ranging constellation 50 (i.e., ranging measurements performed on ranging reference signals between the device UE 10 and one or more anchor UEs of the ranging constellation) may be used by the anchor UE 14 to locally calculate the location coordinates of the device UE 10 (using any of the concepts described in this disclosure) based on the device UE 10's own location information obtained from a location service or additional location module provided on the anchor UE 14 and the ranging measurements with the device UE 10.

[0291] It should be noted that the anchor UE 14 may also inform the device UE 10 of the local coordinate system used by the ranging constellation 50 and the expected level of accuracy for a given ranging measurement performed between the device UE 10 and the anchor UE 14. If the ranging constellation 50 supports multiple coordinate systems, the anchor UE 14 may inform the device UE 10 of the different types of coordinate systems supported by the ranging constellation 50. The device UE 10 may select one of the supported coordinate systems or let the anchor UE 14 determine the default coordinate system for a given device UE 10 based on its device characteristics. Note that local coordinates using such a coordinate system may be converted to geographic coordinates by the anchor UE 14 or another device UE 10 that may act as a proxy for a location service, or by the location service of the wireless access device 20 or the LMF 34, RMF 36, or other location or ranging services provided / accessible by the core network upon request by the device UE 10. To this end, a UE with ranging capability may send a message through a secure interface to the LMF 34, RMF 36 or other location and / or ranging service in the core network, or provided by an access device or the LMF 34, RMF 36 or a proxy of other location and / or ranging services provided by another UE with ranging capability (e.g., anchor UE 14), wherein the message includes distance and / or angle measurements (e.g., based on ranging reference signals), and optionally includes other information (such as ID and / or timing information, or distance and / or angle calculation results (e.g., based on range measurements), and optionally the location coordinate system used), and optionally includes altitude and / or velocity / accelerometer information, whereby after the LMF 34, RMF 36 or other location / ranging service or location / ranging service proxy receives the message, a response message is returned, which includes the obtained location coordinates calculated using the indicated optional location coordinate system or the default (e.g., geographic) coordinate system.

[0292] To allow the LMF 34, RMF 36 or other location and / or ranging service or its proxy to calculate position or distance / angle, the device UE 10 may grant permission by providing authorization credentials that can be used to authenticate / verify that the authorization is authentic (i.e., provided by the device UE 10) to the LMF 34, RMF 36 or other location or ranging service or its proxy as part of the same message or a subsequent message, for example, by performing a corresponding authentication process with the device UE 10, or by verifying that the credentials match or can be securely associated with previously stored credentials of the device UE 10 in the LMF 34, RMF 36 or other location and / or ranging service or its proxy, or a core network function (e.g., UDM / AUSF), and / or by granting this permission via providing consent in its subscription (e.g., by the UDM) or by providing consent via a network exposure function (NEF). The message that may be sent by the device UE10 to express consent to this may include fields / payloads containing information about the given consent, such as the validity period, to which entity the consent is given (e.g. a location service agent (provided by a specific UE that may include the identity)), information about credentials or tokens that must be provided by the given entity before the given entity is allowed to participate in calculating the position or distance / angle of the device UE 10. In the case where a group / domain credential or authorization token or a closed access group or NPN or (private) network slice is associated with a ranging constellation, which is used to protect communications between UEs of the ranging constellation and / or restrict communications only between UEs belonging to the group / domain / closed access group / NNP / slice, the device UE 10 may only need to provide consent once for all UEs of the ranging constellation to participate in calculating the position or distance / angle of the device UE 10 (for example, by including in a message the ranging constellation ID and / or group / domain credential and / or closed access group or NPN or (private) network slice information to which the consent will be associated, which the device UE 10 sends to the LMF 34, RMF 36 or other location and / or ranging service or its agent, or other management entity). For example, this can be done during the message exchange when the target UE joins the ranging constellation (for example, when a request for ranging or position estimation is issued to the LMF or its agent). The consent can also be stored in the UDM or GMLC (typically in the target UE's home network) and can be verified, for example, by the AMF or other core network function. The consent may also be provided by the application managing (via the NEF) the ranging constellation and / or the involved UEs, for example by providing it implicitly or explicitly in the ranging constellation configuration information it may send to the LMF or other management entity.

[0293] Similarly, for similar messages that may also include location information or an identifier of a device or reference point, a UE with ranging capability may request the location and / or ranging service (or its agent) to provide / calculate / return the distance and / or angle between the UE with ranging capability and the indicated device or reference point, after which the LMF 34, RMF 36 or other location and / or ranging service (or its agent) will return the resulting calculated distance and / or angle.

[0294] According to some other embodiments related to decentralized positioning based on ranging measurements with anchor UEs 14, the ranging constellation 50 can be configured and deployed in an indoor environment or a known target area so that it can have its own local coordinate system relative to a reference geographic coordinate system. A device UE 10 that is close to the ranging constellation 50 and authorized to use the ranging constellation 50 can request location coordinates from an anchor UE 14 in the ranging constellation 50. Upon receiving the request, the anchor UE 14 itself or a head device of the ranging constellation 50 on its behalf can select at least one (typically two or three) of the anchor UEs 14 in the ranging constellation 50 to perform ranging measurements with the device UE 10, so that the selected device is within a desired ranging distance of the device UE 10 and can perform ranging with the device UE 10 to calculate the location of the device UE 10 according to the local coordinate system in the ranging constellation 50. The selected anchor UE 14 of the ranging constellation 50 can initiate ranging measurements with the device UE 10, for example, in a synchronized or coordinated manner, to obtain ranging measurements. The ranging measurements may be used by the head device of the ranging constellation 50 or by the ranging service in conjunction with the location service (or its proxy) to locate the device UE 10 in a local coordinate system within the ranging constellation 50. Coordination may be performed by performing ranging measurements sequentially in time to avoid initiating all measurements at the same time and thereby interfering with each other. This may also mean performing ranging measurements relatively close together in time to obtain accurate results when the device UE 10 is moving.

[0295] It should be noted that to protect the privacy of the ranging process, specific ranging parameters (e.g., constellation identifier, anchor UE identifier, information about the ranging reference signal used by the first UE at a given moment) and / or information embedded / added / multiplexed into the ranging reference signal (e.g., identifier) ​​and / or ranging measurements / results may be transmitted to the second UE only after the second UE has been authorized to use the ranging reference information of the first UE. To prevent UE tracking based on the ranging reference signal and / or positioning message broadcast by the UE, the identity and / or resources (timing / frequency) of the ranging reference signal or positioning message may be randomly assigned. For example, the signal / message may follow a random search pattern known only to authorized devices, rather than a well-known or deterministic pattern (e.g., a periodic pattern of signals / messages sent at periodic / specific times / frequencies). Furthermore, after each ranging session, before or after establishing a new ranging session, the UE may need to request a new / fresh authorization or may have to receive a new / fresh authorization and / or obtain a new / fresh set of credentials from the core network / access device / RMF / LMF / (head) anchor UE over a Uu direct connection or a PC5 direct / indirect connection.

[0296] In one example, if authorized for ProSe-based ranging / positioning services, the device UE 10 may approach an area and may be provided with ProSe discovery parameters (e.g., a ProSe service / application identifier for ranging / positioning services or a discovery key for discovering anchor UEs and / or ranging / positioning services). Based on these ProSe discovery parameters, the device UE 10 may discover other UEs with ranging capabilities (e.g., anchor UE 14) in the area, which may use one of the ProSe discovery procedures. Once discovery is performed and a PC5 secure connection is used, or directly in the discovery message itself (e.g., as part of a metadata field), the anchor UE 14 may provide the ranging / positioning services requested by the device UE 10 with the specific parameters required for ranging / positioning (e.g., positioning signal ID or timing / frequency of the positioning signal). It is worth noting that, as described in the initial section above, ranging can be performed in a variety of ways. For example, the device UE 10 may be equipped with beamforming capabilities so that ranging measurements can be directed toward a certain anchor UE 14, and this "angle" information can be used to determine its position.

[0297] According to some embodiments related to decentralized positioning based on ranging measurements with anchor UEs 14, the device UE 10 may receive an updated list of anchor UEs 14 located in its vicinity, for example, from the LMF 34 or RMF 36 or other management entity. Note that the LMF 34 and / or RMF 36 or other management entity may create and continuously update this list of anchor UEs 14, thereby generating a continuously updated constellation of ranging-capable UEs whose locations are known a priori to the LMF 34 and / or RMF 36 or other management entity. Optionally, in order to provide control to the network operator, the device UE 10 may be required to report measurement results (e.g., as performed on ranging reference signals received from one or more anchor UEs) and an indication of the location of the device UE 10 to the LMF 34 and / or LMF 36 or other management entity.

[0298] Note that if the PC5 interface is required, the device UE 10 and the anchor UE 14 need to discover each other. Therefore, the LMF 34 or RMF 36 or other management entity may need to interface with a network function in the 5G CN (e.g., Direct Discovery Name Management Function (DDNMF) or Policy Control Function (PCF)), which can authorize the device UE 10 to discover the anchor UE 14 through (PC5) discovery messages.

[0299] When the device UE 10 approaches and enters the ranging range of one of the anchor UEs 14 of the ranging constellation 50 , it may be assisted in obtaining its position coordinates through ranging measurements without being actually positioned by the network access device 20 and / or the LMF 34 .

[0300] According to some other embodiments related to decentralized positioning based on ranging measurements with an anchor UE 14, which can be used as an alternative to or in combination with the corresponding embodiments described above, an out-of-coverage device UE 10 can request its current location information from a communicatively coupled anchor UE 14 that is calibrated for ranging measurements with the device UE 10, for example, by sending a message with measurement results related to a ranging reference signal (whereby such measurement results may include, for example, the device ID or the ranging reference signal ID and / or timing information) and / or an estimated distance / angle to the anchor UE 14, optionally including information about the coordinate system to be used, and optionally including altitude and / or velocity / accelerometer information. The message type (e.g., PC5_Location_Request or RRCLocationRequest) can indicate to the anchor UE 14 that the device UE 10 is requesting location information based on the provided information, and the device UE 10 can return this information to the device UE 10 in a response message (after calculation).

[0301] Similarly, for similar messages that may also include location information or an identifier of a device or reference point, the device UE 10 may request the anchor UE 14 to provide / calculate / return the distance and / or angle between the device UE 10 and the anchor UE 14 and / or the indicated device or reference point, after which the anchor UE 14 will return the resulting calculated distance and / or angle. The anchor UE 14 may know its own location, or may request its own location coordinates from the LMF 34 or RMF 36 or other location services of the core network 30 (e.g., a network controller device) based on positioning measurements with the network access device 20 (e.g., a gNB), and convert the ranging measurements of the device UE 10 into the local location coordinates of the device UE 10.

[0302] Alternatively, the anchor UE 14 may report the ranging measurements of the device UE 10 together with its device ID to the LMF 34 or RMF 36 to obtain the position coordinates of the device UE 10, which are then calculated by the LMF or RMF.

[0303] Alternatively, the position coordinates of the anchor UE 14 may be shared with the device UE 10, which may use its ranging measurements and the position coordinates of the anchor UE 14 to calculate its own position coordinates.

[0304] According to some embodiments related to decentralized positioning based on ranging measurements with an anchor UE 14, an anchor UE present in the ranging constellation 50 may be configured to advertise a (ranging-based) positioning service (or its proxy) as a proximity service. Note that this may require assigning some anchor UEs 14 to the ranging proximity service. This may require the LMF 34 or RMF 36, or other management entity, to interact with a Direct Discovery Name Management Function (DDNMF) or Policy Control Function (PCF), which is responsible for assigning discovery parameters to UEs. After connecting to the ranging-based proximity service, subscribing to, and / or authorizing the proximity service for ranging-based positioning, the device UE 10 may receive discovery keys / parameters for accessing the ranging / positioning service (or its proxy) (e.g., via a PC5 sidelink channel). The device UE 10 may then securely send (or receive) discovery messages (e.g., via PC5 sidelink discovery messages) for the ranging-based positioning service (or its proxy) for the anchor UE 14 in the ranging constellation 50.

[0305] The management entity PCF, AUSF, LMF 34 or RMF 36 may provide credentials to the device UE 10 (e.g., during initial configuration of the ranging / location service on the device UE 10, or during an authorization / connection establishment procedure between the device UE 10 and the anchor UE 14, which may involve an exchange of messages between the anchor UE and the corresponding network function, after which the anchor UE 14 may forward data to the device UE 10 via a relay connection through the anchor UE 14 and / or forward message exchanges between the device UE 10 and the corresponding network function), which the device UE 10 should use to securely connect to the ranging / location service (or its proxy) and / or for protecting data sent by the device UE 10 to, or received from, the ranging / location service (or its proxy). Alternatively, the device UE 10 together with the management entity, PCF, AUSF, LMF 34 or RMF 36 may derive credentials (e.g. keys) based on a set of pre-configured credentials (e.g. root credentials in the SIM, or e.g. session keys such as KAMF or KAUSF, or application keys) for securely connecting to the ranging / location service (or its proxy) and / or for protecting data that the device UE 10 sends to the ranging / location service (or its proxy) or that the device UE 10 may receive from the ranging / location service (or its proxy).

[0306] After receiving (or sending) a discovery message, the anchor UE 14 of the ranging constellation 50 may reply with (or include) a position and / or ranging measurement or a calculated ranging result, depending on its device capabilities. This may be accomplished via a discovery message or by configuring a lower protocol layer (e.g., a physical (PHY) layer) to begin transmitting positioning signals, communicating the timing and / or frequency and / or identity of the positioning signals to the device UE 10 (e.g., via a PC5 interface), and collecting UE measurements of the received positioning signals or calculated ranging results based on measurements on the PC5 interface.

[0307] For example, after successful discovery as described in other embodiments, the anchor UE 14 can provide a set of ranging parameters (e.g., the timing and identification of the positioning signal assigned to the anchor UE 14 or other configuration parameters or desired ranging parameters) to the device UE 10 through direct device-to-device communication or discovery (e.g., using sidelink / PC5). This approach is useful for device UEs 10 that are out of coverage, because the device UE 10 can then only receive these parameters from other UEs with ranging capabilities through direct device-to-device communication or discovery (e.g., using sidelink / PC5). Alternatively, the device UE 10 can receive the ranging parameters of the anchor UE 14 when joining a ranging service and / or a location service and / or a ranging-based positioning service, for example, after authentication and authorization.

[0308] According to some embodiments, if there are multiple UEs with ranging capabilities, such as anchor UE 14 (which have responded to device UE 10 with a ranging reference signal (e.g., a discovery message) or have voluntarily sent a ranging reference signal), device UE 10 can estimate the distance and / or angle based on the timing measurement of each ranging reference signal (e.g., a discovery message), and use the estimated distance and / or angle to estimate the position through, for example, triangulation / trilateration. To this end, the UE (e.g., anchor UE 14) that transmits the ranging reference signal (e.g., a discovery message) can send a synchronization signal and / or timing information to the receiving device (e.g., device UE 10). Alternatively or additionally, the timing of the scheduling resource used for discovery (e.g., a sidelink discovery pool) or the ranging / ranging reference signal pool can be used to determine the start time of transmitting the ranging reference signal (e.g., a discovery message). The ranging reference signal (e.g., discovery message) may include timestamp information or time difference information about when it was sent (e.g., t4-t1 and / or t3-t2 in the case of FTM-based technology). The ranging reference signal (e.g., discovery message) may include departure angle information. The device UE 10 may perform the same operation in its ranging reference signal (e.g., discovery message) to another UE with ranging capability (e.g., anchor UE 14). Alternatively, when only a few (e.g., one) UEs 14 respond to the device UE 10, and / or if the ranging reference signal (e.g., discovery message) includes location and time of departure (TOD) information, and the clocks of the device UE 10 and anchor UE 14 are synchronized, the device UE 10 may calculate the distance based solely on the ranging reference signal (e.g., discovery message) and, if sufficient information is available (e.g., if it can also measure angles and / or if information about altitude is provided to / from the other UE), it may estimate its position. This reduces the need for the device UE 10 to send other messages (such as specific ranging / position / sounding reference signals) to the anchor UE 14 for positioning information.

[0309] Chapter: Randomized Ranging Reference Signal

[0310] According to some embodiments related to positioning signals from anchor UE 14 or target UE 10, a configuration entity (e.g., a management entity) may assign a potentially irregular, random lookup allocation of positioning signals, such as transmission times / schedules and / or positioning signal IDs and / or timing / frequency patterns, to anchor UE 14 and target UE 10. Positioning signal p0 is used at time t0, positioning signal p1 is used at time t1, positioning signal p2 is used at time t2, ..., positioning signal pi is used at time ti, ..., and positioning signal pj is used at time tj. Positioning signals pi and pj may be selected randomly or in a random lookup manner from a set of available positioning signals, which may be identified by positioning signal IDs and whose characteristics may be preconfigured by the configuration entity. Furthermore, the resources used to transmit the positioning signals may be selected randomly or in a random lookup manner from a set of available resources in the area. Furthermore, the time interval (ti+1–ti) between consecutive signal transmissions may not be a fixed value. Consequently, it is difficult to track UEs transmitting positioning signals on sidelink channels, and UEs can only use these positioning signals if they are informed of their timing and identification over time. At a given time, the positioning signal identifier may have a one-to-one or many-to-one relationship with the anchor UE identifier or the target UE identifier, or may have a many-to-many relationship with a set of identifiers of the anchor UE or the target UE at a given time. Both the transmitter UE and the receiver UE involved in ranging using the corresponding random search positioning signal need to be configured with information about the timing and the positioning signal identifier and / or the UE identifier changing over time. The above-mentioned positioning signals p1, p2, ..., pi may be standard signals (for example, as defined in TS 36.211), or may be different in waveform, bandwidth, preamble, carrier, guard band, and / or may include a pattern indicating the positioning signal ID or anchor UE identifier or target UE identifier, and may correspond to different positioning signal IDs, or anchor UE identifiers, or target UE identifiers at times t1, t2, ..., ti. The positioning signal ID or anchor UE identifier or target UE identifier may determine, for example, a pseudo-random sequence (e.g., associated with the positioning signal ID, anchor UE identifier, or target UE identifier at a given moment) or an encrypted / scrambled positioning signal ID or anchor UE identifier or target UE identifier that is part of, encapsulated by, or sent via the positioning signal, or may determine a frequency shift of the positioning signal. The anchor UE identifier, target UE identifier, and / or positioning signal ID may also be used to determine / select radio resources for sending / receiving positioning signals. To this end, an access device or a management entity may define resources for each positioning signal ID or each anchor UE identifier or each target UE identifier, and provide resource allocation information to the UEs involved (e.g., all UEs in a constellation). The management entity may have to ensure that multiple anchor UEs and / or target UEs in the vicinity do not interfere with each other.Therefore, the management entity may need to assign an anchor UE identity, a target UE identity, and / or a positioning signal ID to each anchor UE or target UE in the area at times t1, t2, ..., ti in a non-conflicting manner (e.g., to ensure that they do not use the same radio resource element at the same time), and may notify the involved UEs (e.g., all UEs in the ranging constellation) of their respective identities using a secure connection or an encrypted message (which only the intended recipient can decrypt). Alternatively, the positioning signal ID, anchor UE identity, or target UE identity may be independently selected by the corresponding anchor UE 14 or target UE 10, for example, based on a preconfigured randomization function (e.g., based on UTC time / system frame number (SFN)), which randomization function may be securely shared with the UEs of the constellation, and may notify the involved UEs (e.g., all UEs in the ranging constellation) of their respective identities using a secure connection or an encrypted message (which only the intended recipient can decrypt). Alternatively, the positioning signal ID or anchor UE identity or target UE identity may be selected by the corresponding anchor UE 14 or target UE 10 according to a preconfigured pseudo-randomization function (e.g., based on UTC time / system frame number (SFN)), whereby the configuration of the pseudo-randomization function may be securely shared with the UEs in the ranging constellation, and the corresponding UEs may use the configuration to derive the same identity.

[0311] According to some embodiments related to the aforementioned embodiments, a management entity utilizes random lookup allocations of positioning signals for service authorization and revocation. The management entity may distribute (i.e., disclose) the random lookup allocations of positioning signals assigned to an anchor UE 14 or target UE 10 only to devices UE 10 or anchor UE 14 that are authorized to use the service (e.g., authorized during an initial configuration phase). A given positioning signal pi among the random lookup positioning signals p1, p2, ...pi, ...pj may have a limited lifetime, such as a few seconds, a few minutes, etc. In this case, if a UE 10 has already been configured with positioning signals pi+1, pi+2, ..., then the UE 10 may be prevented (revoked) from using the ranging service by updating the random lookup allocations of positioning signals pi+1, pi+2, ... for the anchor UE 14 and any other anchor UEs that the UE 10 may rely on. Alternatively, the management entity may disclose to the UE 10 only positioning signals assigned to the anchor UE that are valid for a very limited time, so that the UE 10 automatically stops accessing the service once the limited amount of time has passed. The two alternatives described above provide a practical way to revoke the use of ranging / location services without having to update the credentials in all related devices to reflect the revoked authorization.

[0312] Chapter: The process of ranging-based positioning services

[0313] Figure 7A signaling and processing diagram summarizing various operational options for ranging-based positioning services according to some embodiments is schematically shown. In the diagram, information exchanges and their directions are represented by corresponding arrows, processing steps are represented by corresponding blocks, and time is shown from Figure 7 The system is structured as follows: The system is constructed from the top of the image to the bottom of the image. The locations where processing steps occur or the start and end points of information exchange are indicated by the vertical dashed lines below the corresponding system components. Not all steps are required, and some steps may be performed multiple times for increased accuracy or continuous ranging-based positioning.

[0314] In an initial configuration step S701, the CN configures the anchor UE (A-UE) in this way, which may include forwarding control information for configuring, for example, discovery parameters, ranging constellation identifiers, positioning signals and parameters and / or positioning techniques. The anchor UE may also be configured with its specific location in this step. This location may also be known (only) to the CN. Then, in a subsequent step S702, the device UE sends a request to the CN to use / subscribe to a ranging-based positioning service. In response, the CN checks whether the device UE is authorized to use this service and, if so, provides the device UE with, for example, discovery parameters, positioning signal parameters and / or (preferably) the ranging method to be used in step S703. Similarly, the CN may also check whether the anchor UE is authorized to participate in the ranging of the device UE. This step completes the initial configuration phase (CP).

[0315] Now, the operation phase (OP) begins at step S704, where the device UE sends a discovery message to the anchor UE to request ranging service. This message can be a restricted discovery message (e.g., ProSe Model B Request), or can be skipped in ProSe Model A, or can be a ProSe Mode A Advertisement, where the device UE requesting ranging service plays the role of the announcing UE. Note that when the device UE sends this message, the device UE may have already received a sidelink synchronization signal allowing it to synchronize with the anchor UE.

[0316] In step S705, the anchor UE may collect the presence of received discovery or connection establishment or ranging session initiation messages, and / or information from these messages (e.g., UE identification information, ranging capabilities, timing information, signal strength information), and send them to the CN. In one example, the leading anchor UE may send a combined report on behalf of the anchor UEs. Alternatively, each anchor UE may send the received messages aggregated in the CN.

[0317] In step S706, the CN may estimate the location of the device UE (e.g., a rough initial estimate) based on the (combined) report received in step S705 and the location of the anchor UE. Alternatively, the CN may perform an initial estimate of the location of the device UE based on the anchor UE report message received in step S705. Depending on the accuracy of the estimated location, the CN may indicate (see step S707b) that a more accurate ranging measurement is required between the anchor UE and the device UE, such as a PRS-based ranging estimate in a subsequent step. In this step, the CN may also verify / obtain authorization and / or user consent for using ranging-based positioning services to determine the location of the device UE and / or whether the anchor UE is authorized to participate therein.

[0318] In step S707a, when ProSe restricted discovery model B has been used, the anchor UE may reply to the device UE with a response message. The message may also indicate that the anchor UE is configured as an advertising UE and uses ProSe advertising discovery messages (model A). The discovery messages may be used (e.g., directly) by the device UE for ranging purposes, or may be used to send configuration data required by the device UE to perform ranging in subsequent steps (e.g., if the device UE is out of range and initially lacks positioning parameters sent by the anchor UE) and / or perform an initial position estimate (e.g., in the case where some or all messages contain position coordinate information of the corresponding anchor UE).

[0319] As an option, a further step 707b may be used, by which the CN sends an indication of the achieved or required accuracy to the anchor UE. Based on this indication from the CN, the anchor UE may (re)configure the ranging procedure, e.g., the transmission of PRS signals for ranging-based position estimation. This may mean that the ranging messages in steps S704-S715 may be exchanged longer, shorter, more frequently, and / or with different signal characteristics. This may also mean that the anchor UE skips the ranging procedure (steps S709 to S717) if the accuracy achieved in step S706 is already sufficient. If this optional step S707b is not present, the normal flow of ranging steps S709 to S717 is followed.

[0320] In step S708, the device UE may obtain an initial distance / position estimate based on the message received from the anchor UE in step S707a, possibly in combination with (the timing and content of) the message sent in step S704. The messages of steps S704 and S707a may be exchanged multiple times to improve accuracy.

[0321] Note that if multiple anchor UEs respond to the device UE in step S707a and some or all response messages contain location coordinate information of respective anchor UEs, the device UE may estimate its location based on these messages received in step S707a by triangulation / trilateration.

[0322] In step S709, the anchor UE may transmit one or more positioning signals that are received by the device UE. Then, in step S710, the device UE may perform an estimate of its distance / position based on the positioning signals received in step S709. If an initial estimate was made in step S708, the estimation in step S710 may improve the accuracy of the initial estimate.

[0323] Alternatively or in combination with the previous step S709, the device UE may also send a positioning signal in step S711, which may be received / measured by the anchor UE. The primary anchor UE may be responsible for collecting these measurements of the anchor UE.

[0324] It should be noted that the UE may also use other (types of) positioning signals (e.g., sounding reference signal (SRS signal) or channel state information reference signal (CSI-RS)) or multiple types of positioning signals in a channel specified or requested by the anchor UE for more accurate ranging measurements.

[0325] In step S712 , the leading anchor UE may locally obtain the location / distance of the device UE based on positioning signals received by the leading anchor UE and / or one or more other anchor UEs.

[0326] In step S713 , the device UE may send the measured and / or calculated distance / angle / position to one or more anchor UEs based on the exchanged discovery messages or positioning signals.

[0327] Then, in step S714, the leading anchor UE may locally obtain the position / distance of the device UE based on the reported measurements and / or calculated distance / angle / position of step S713. In the case where the position / distance of the device UE has already been determined locally in step S712, this may be an improved estimate based on the additional information provided by the reported measurements in step S713.

[0328] If the leading anchor UE calculates the position / distance of the device UE, the leading anchor UE may send the information to the device UE in step S715. Similarly, if another anchor UE calculates its distance to the device UE, it may also send the information to the device UE in step S715.

[0329] In addition, in step S716, the leading anchor UE (or any other anchor UE or UE with ranging capability or relay device) may send the received measurements to the CN, and the CN then estimates the position / distance of the device UE in step S717. Typically, when the leading anchor UE is in coverage, it sends these measurements directly via the access device, but when it is out of coverage, it may delegate this task to another UE of the ranging constellation, or it may send these measurements indirectly via a relay device (e.g., ProSe UE to network relay UE).

[0330] Finally, in step S718, the CN may export the ranging / position information to an external application function (AF) after authentication and authorization of the AF.

[0331] chapter: Protect PRS signal privacy and / or use multicast / broadcast for ranging

[0332] according to Figure 9 In some embodiments shown, the positioning / ranging process may include session-less ranging, but the techniques in this embodiment may also be applicable to other processes or standalone implementations. Benefits of session-less ranging include: (i) it allows focus on protecting a limited set of messages, and (ii) such session-less ranging operations allow for enhanced performance. It may not always be necessary Figure 9 The multiple steps described in Figure 9 In FIG, three UE (10) devices, namely UE1, UE2 and UE3, perform ranging / positioning operations. Note that the figure only shows three UE devices, but can be generalized to involve more than three UE devices. Figure 9 The group of UE devices in a may together form a ranging constellation.

[0333] The three UE devices receive support from the CN (30) and all entities (network functions) therein, for example to obtain authorization or receive ranging parameters. Figure 9 It is not explicitly stated in , but external AF may also be involved.

[0334] This support phase is explicit in the initial configuration phase (CP) and is illustrated by step S900, where each UE device (i.e. Figure 9 The initial configuration and authorization of UE1, UE2 and UE3 in the network are performed by the CN.

[0335] Figure 9 A possible variation is: UE2 is a UE that requires ranging / positioning operations, and UE1 and UE3 are anchor UEs that provide ranging / positioning services.

[0336] In a first step 900, a UE that is authorized to use or provide ranging / positioning services is configured with ranging / positioning parameters, for example, as described in the above embodiments and descriptions.

[0337] In addition, if authorized to participate in ranging / positioning, the UE device is provided with certain cryptographic keys for use in subsequent message exchanges. For example, these cryptographic keys can be discovery keys according to TS 33.503, namely DUIK, DUCK, and DUSK, which allow ranging / positioning discovery to be performed in a secure manner. Alternatively, for example, the UE device is provided with credentials for protecting groupcast / multicast / broadcast messages (e.g., group keys) on the PC5 / sidelink, thereby enabling groupcast / multicast / broadcast to be performed according to TS 23.304 (i.e., with group discovery) or TS 23.287 (i.e., without group discovery), and thereby protecting group discovery with different credentials than groupcast / multicast / broadcast messages (e.g., using DUIK, DUCK, and / or DUSK shared among group members).

[0338] Each UE is also provided with a configuration of ranging parameters that allows ranging to be performed in a privacy-aware manner, e.g., preventing UE2 from being tracked. In one possible variant, UE1 and UE3 are anchor UEs, e.g., at fixed known locations (e.g., fixed locations along the road that UE2 is moving on in a V2X scenario), and are therefore provided with discovery keys and / or groupcast / multicast / broadcast credentials.

[0339] These discovery keys and / or groupcast / multicast / broadcast credentials can be rotated / changed over time (e.g., valid only for a limited period of time, such as 1 minute, 1 hour, or 1 day). These discovery keys and / or groupcast / multicast / broadcast credentials can be configured for UEs in close proximity, such as close to (e.g., within 100 meters, 1 km, or 10 km of) an anchor UE. Furthermore, to ensure service continuity, discovery parameters such as discovery keys and / or groupcast / multicast / broadcast parameters such as group keys can be deployed with some overlap in time / location settings.

[0340] In step S900, each reference UE (e.g., UE1 and UE3) is assigned one or more PRSs to be used in messages S911 or S913 and one or more PRS's that UE2 can use in messages S912 or S914. To avoid tracking and reduce interference, different PRS and PRS' signals should be assigned to adjacent reference UEs. To avoid tracking, the assigned PRS and PRS' signals can be rotated / changed periodically. Note that for simplicity, PRS is used here, but PRS can also be similarly replaced by another type of positioning / ranging reference signal (such as SRS).

[0341] In this stage S900, each UE interacts with the CN (e.g., LMF, AUSF / UDM) or other management entity to obtain authorization to provide (e.g., UE1 and UE3) or use (e.g., UE2) the ranging service. After authorization, each UE is configured with ranging information to provide or use the ranging service, discovery information for the ranging service, and / or the necessary information to perform groupcast / multicast / broadcast for ranging. This discovery information includes a discovery key. Information for performing groupcast / multicast / broadcast includes groupcast / multicast / broadcast credentials.

[0342] At this stage, each UE may be configured with a policy that determines whether the UE is allowed to provide / use session-less ranging operations, ie, ranging operations with reduced signaling overhead.

[0343] According to some embodiments that can be used independently, the PRS assigned to a UE (e.g., an anchor UE) is derived from an identifier determined and / or managed by the RAN or CN so that the RAN or CN can ensure that different UEs receive different sets of PRSs as described above. This "application identifier" can be used as an input in the PRS generation process, for example, as in the current PRS definition in clause 7.4.1.7 of TS 38.211, which describes how to derive the PRS from multiple parameters including the identifier. This "application identifier" can be used as an input parameter for PRS generation instead of, for example, the dl-PRS-SequenceID. Additionally or alternatively, the "application identifier" can be used as an additional input parameter in the process of deriving the PRS signal, for example based on clause 7.4.1.7 of TS 38.211.

[0344] In the second step S910 already in the operational phase (OP), the UE device performs discovery and / or configuration of ranging / positioning operations. In this second step, the anchor UE UE1 (and UE3) sends a message S911 (S913).

[0345] The message may be a request discovery message according to discovery model B protected by the discovery key configured in step 900, or may be a groupcast / multicast / broadcast message that may include configuration information for ranging / positioning operations protected by using the multicast / multicast / broadcast credentials configured in step 900.

[0346] The discovery message (eg, request discovery message) or the groupcast / multicast / broadcast message may include a service code identifying the provided ranging / positioning service or session.

[0347] The discovery message (eg, request discovery message) or groupcast / multicast / broadcast message may also include an indication of support for sessionless operation capability.

[0348] A UE device that requires positioning / ranging operation (eg, UE2) or a UE device that participates in positioning / ranging operation (eg, UE3) will receive the message and process it using a preconfigured discovery key or groupcast / multicast / broadcast credentials.

[0349] If the key or groupcast / multicast / broadcast credentials are found to be appropriate (which also means that the UE is authorized), the UE will be able to descramble, decrypt, and integrity verify the message. When doing so, UE2 (and other UEs participating in the location / ranging operation (e.g., UE3)) can access the ranging / positioning parameters required for ranging / positioning operations with the anchor UE UE1 (similar to UE3).

[0350] Such ranging / positioning parameters may be as described above and include the PRS used, timing parameters or their locations.

[0351] After receiving and processing the message S911 (S913), UE2 prepares a message S912 (S914) towards the device UE1 (UE3). Other involved UEs (eg, UE3) may also do the same (not shown in the figure).

[0352] This message S912 is prepared in a similar manner and may correspond to a discovery response message according to discovery model B. If UE2 has been authorized to use sessionless operation, the discovery response message may include an indication of acceptance / use of sessionless operation. Alternatively, a discovery response message is sent only if sessionless operation is accepted. The ranging / positioning parameters exchanged in the discovery message may be exchanged in a metadata field of the discovery message (e.g., using an encapsulated (extended) LPP command or similar).

[0353] Similarly, in the case of groupcast / multicast / broadcast operation, message S912 / S914 may correspond to a groupcast / multicast message (which may use the L2 identifier used in the received message S911 / S913 or a pre-configured L2 groupcast / multicast / broadcast identifier as the destination address). The message may include an indication of accepting / using sessionless operation and may include a set of ranging / positioning parameters.

[0354] When UE2 sends messages S912 and S914, the two messages may be of the same type and may be protected with the same key, for example, they may be discovery response messages protected with corresponding discovery keys. Therefore, it may be important to include parameters in these messages so that the receiving UEs (e.g., UE1 and UE3) know which message is intended for them. For example, message S912 (S914) may include an identifier that was first included in message S911 (S913). This identifier may be an explicit (short) (session) ID selected or assigned by UE1 (or UE3), or it may be another parameter exchanged in message S911 (S912) and indicates the entire message, such as the MIC in message S911 (S912). The identifier of message S911 may be included in message S912 so that the receiving UE device knows that the message is intended for it. The same may be done for message S914.

[0355] Messages S912 and S914 may be combined, e.g., they may be a single broadcast message intended for UE1 and UE3 (e.g., when both UE1 and UE2 are expected to participate in ranging / sidelink positioning operations with UE2, e.g., because they are both part of the same ranging constellation or the same group).

[0356] The message flow in step S910 is described in the context of discovery model B or a groupcast / multicast / broadcast communication model in which the anchor UE (e.g., UE1 or UE3) is the initiating UE. In the case of discovery model A, a single message may be sent by (i) UE2 or (ii) the notifying UE of UE1 (and UE3). In the first case, UE2 sends a discovery message, which may include a field indicating support for session-less ranging operation capability and / or a request to initiate a session-less ranging operation. In the second case, UE2 receives two discovery messages. In the case of a groupcast / multicast / broadcast communication model in which UE2 is the initiating UE, UE2 sends a groupcast / multicast / broadcast message, which is then received by the anchor UEs (e.g., UE1 and UE3), wherein the groupcast / multicast / broadcast message may include a field indicating support for session-less ranging operation capability and / or a request to initiate a session-less ranging operation.

[0357] In step S920 , the UE device transmits and measures ranging / positioning signals such as PRS / SRS / etc.

[0358] The PRS signal may be allocated to the UE in S900 (eg, by the LMF or other management entity), or configured in S910 (eg, by the head-anchor UE).

[0359] The PRS signals should be distributed in a manner that minimizes privacy issues, for example, the UE (eg, UE2) rotates the broadcasted PRS periodically.

[0360] According to some embodiments, in step S900, the CN (e.g., LMF) or RAN (e.g., gNB) or other management entity has allocated a given schedule of PRSs to be used to the UE (e.g., UE2). The CN or RAN needs to configure the same schedule in UE1 (and UE3) to ensure that UE1 (and UE3) can determine the UE that sent the information.

[0361] According to some embodiments, an option is to have UE1 allocate PRSs to UE2 in message S921. This allows for distributed operation, thereby reducing signaling between the RAN and CN during operation. For example, UE1 may have several allocated PRSs' (assigned by the CN or other management entity in S900), which UE1 can allocate to UEs (e.g., UE2) that require ranging services.

[0362] In the special case of the last option, each UE providing ranging services is assigned a single, distinct PRS. After exchanging messages S911 and S912, UE2 knows (using the provided configuration information) the PRS assigned to UE1 and the PRS UE1 will use in message S921. After receiving message S921 (UE1's PRS), UE2 responds with message S922 using the same PRS or its own PRS for UE2. This approach ensures that UEs requiring ranging / positioning services (e.g., UE2) use different PRSs to avoid tracking and avoids conflicts between UEs requiring ranging.

[0363] In the special case of the last option, neighboring UEs providing ranging services are allocated different PRSs or different PRS timing / frequency in a manner that minimizes interference.

[0364] In the special case of the last option, the neighboring UE providing ranging service is allocated (in S900) different PRS random search sequences to be used in a given time period. For example, UE1 can be configured with a PRS set: PRS1, PRS3, PRS7, ... to be used in time slots t0, t1, t2, ..., while UE3 can be configured with a PRS set: PRS2, PRS1, PRS6, ... to be used in time slots t0, t1, t2, .... Then, in steps S921 and S923, UE1 and UE3 can further allocate such PRSs to UEs (e.g., UE2) that require ranging / positioning services.

[0365] In the special case of the last option, the UE providing the ranging service is assigned (in S900) different PRS random search sequences to be used by itself and by the UE requiring the ranging / positioning service in a given time period. For example, UE1 may be configured with a PRS set: PRS1, PRS3, PRS7, ... to be used in time slots t0, t1, t2, ..., and UE1 may be configured with a PRS' set: PRS2, PRS1, PRS6, ... to be used by the UE requiring the ranging / positioning service (e.g., UE2) in time slots t0, t1, t2, .... This has the advantage of increasing the resilience of the ranging protocol, since an attacker aiming to interfere with the ranging process (by sending a false PRS in a message S922 or S924) does not know which PRS to use.

[0366] In the special case of the last option, a first UE providing ranging services is allocated (in S900) a set of PRSs that can be used by a second UE requiring ranging / positioning services. For example, UE1 may be configured with a PRS' set of: PRS2, PRS1, PRS6. This PRS' set may be indicated to a UE (e.g., UE2) in, for example, messages S911 or S913. The UE may then randomly select one of the possible PRSs in the PRS' set and securely send this selection to the other party in, for example, messages S912 or S914.

[0367] In step S930, ranging measurements are exchanged, for example, as described in the above embodiments / descriptions. Messages S931 and S932 for UE1-UE2 (similar to messages S933 and S934 for UE2-UE3) are used to securely exchange measurements, such as timing measurements in the RRT method, by discovering key material. In the case of a multicast / multicast / broadcast communication model, these messages may be multicast / multicast / broadcast messages, which are then received by the UE / all UEs participating in the ranging / sidelink positioning operation and are protected by multicast / multicast / broadcast credentials.

[0368] In one option, in order to ensure that the messages in step S910 and step S930 are linked to each other, the messages in step S910 and step S930 may include at least a session identifier.

[0369] In another option, these messages are discovery messages that are reused for exchanging measurements, for example in the metadata field. These discovery messages can be protected using discovery key material. These discovery messages can be distinguished from the discovery messages in step S910 by using different service codes. In order to ensure that the messages in step S910 and step S930 are linked to each other, the messages in step S910 and step S930 may include at least a session identifier, which may be assigned, for example, by the UE that starts the discovery process or sends an initial groupcast / multicast / broadcast message to initiate ranging. The ID may be explicit (new ID) or implicit, for example being one or more fields exchanged in the discovery message or multicast / multicast / broadcast message in step S910, for example the MIC included in messages S911 and S913.

[0370] As a second alternative, message S931 is a Direct Communication Request extended to include protected measurements, for example according to clause 6.3.5 of TS 33.503. Message S932 is a Direct Communication Accept extended to include protected measurements, which will also be protected in a similar manner to the DCR message in clause 6.3.5 of TS 33.503.

[0371] As a third alternative, messages S931 and S932 are PC5 protected messages, where the key used to protect these messages may be based on:

[0372] PC5 keys established with or without network support,

[0373] For example, the PC5 key distributed in advance in step S900.

[0374] In step S940, the distance / position is obtained. For example, the distance between UE1 and UE2 and between UE2 and UE3. For example, if the RTT method is used and the direction information is available (or for example, the altitude of UE2 is known) and the messages S911 and S913 include the positions of UE1 and UE3, UE2 can determine its position by itself in step S942. For example, if UE1 and UE3 exchange received measurements, UE1 and / or UE3 can determine the position of UE2. In the case of a groupcast / multicast / broadcast communication model, the UE that calculates the distance / position can send a multicast / multicast / broadcast message including the calculated distance / position, which will then be received by the UEs participating in the ranging / sidelink positioning operation and protected by the multicast / multicast / broadcast credentials.

[0375] This solution addresses the need for privacy protection with respect to ranging positioning services, as privacy issues are addressed using the existing discovery process, as protecting the scrambling operation in the discovery messages prevents or at least makes tracking of the UE more difficult.

[0376] This solution addresses the privacy protection of ranging positioning services, as any authorized UE participating in ranging operations with any authorized reference UE will use the same PRS as the authorized reference UE. This also means that when a UE requiring ranging services performs ranging operations with different reference UEs, it changes the PRS used, making tracking more difficult.

[0377] This solution addresses the authorization of ranging positioning services because during the initial authorization and configuration phase, only authorized UEs can be provided with ranging parameters and discovery keys, and therefore only authorized UEs can participate in the process.

[0378] This solution protects discovery messages by reusing the existing discovery process.

[0379] According to some embodiments that can be used independently, the PRS assigned to a UE (e.g., an anchor UE) is derived from a RAN identifier (such as an RNTI or L2 identifier for PC5 communication). For example, as in the current PRS definition in clause 7.4.1.7 of TS 38.211, which describes how the PRS is derived from multiple parameters including an identifier (e.g., dl-PRS-SequenceID), the RAN identifier can be used as an input parameter for PRS generation instead of, for example, dl-PRS-SequenceID. Additionally or alternatively, the RAN identifier can be used as an additional input parameter in the process of deriving the PRS signal, for example based on clause 7.4.1.7 of TS 38.211. This has the following advantages: (1) PRS management is simplified because the PRS is linked to an existing RAN assigned identifier; (2) PRS conflicts are avoided; and (3) security risks are implicitly reduced because the RAN identifier may have been rotated.

[0380] Therefore, according to the general definition of the first aspect of the present embodiment, an apparatus for obtaining a distance or position estimate of a target mobile device (10) within a wireless network is proposed, wherein the apparatus is adapted to be provided with a ranging positioning signal identifier SL-PRS sequence ID by a management entity, and the apparatus is configured to generate and broadcast a ranging positioning signal on a PC5 interface using the SL-PRS sequence ID, and to perform a distance or position estimate or ranging measurement using the ranging positioning signal. Optionally, the apparatus may be provided with a ranging positioning signal identifier SL-PRS sequence ID, which is assigned to an anchor device with ranging capability by a ranging-capable anchor device or by a management entity, and the apparatus performs a distance or position estimate or ranging measurement using a received ranging positioning signal determined by the provided SL-PRS sequence ID.

[0381] According to another aspect of the present embodiment, a method for obtaining a range or position estimate of a target mobile device (10) within a wireless network is provided, wherein the method comprises:

[0382] - the target mobile device receives a ranging positioning signal identifier SL-PRS sequence ID from a management entity, and

[0383] - The target mobile device generates and broadcasts a ranging positioning signal over the PC5 interface using the SL-PRS sequence ID, and performs distance or position estimation or ranging measurement using the ranging positioning signal.

[0384] chapter: Multicast / broadcast-based ranging

[0385] According to 3GPP TR 23700-86v1.2.0 Figure 6 Some of the embodiments shown in .19.3.1-1 describe a similar positioning / ranging process in the context of a ranging protocol - exchanging messages over the SR5 reference point running on top of the PC5 interface - in Figure 6 The specific case of .19.2.1-1 is enabled by the Device and Service Discovery Function (DSDF), Sidelink Positioning and Ranging Function (SPRF), and Group Support Service Function (GSSF) services / protocols. Figure 6 .19.3.1-1 involves n>=2 UEs. The process is similar to Figure 9 These techniques can also be applied to other processes or used independently. Figure 6 .19.3.1-1, step 1 is discovery via a ranging discovery protocol, e.g. enabled by DSDF; step 2 may establish a positioning / ranging session using GSSF and / or SPRF; step 3 involves exchanging positioning / ranging capabilities using, e.g., SPRF on PC5; and step 4 includes configuration of transmission and measurement of sidelink reference signals. Figure 6 Step 5 in .19.3.1-1 describes the transmission and measurement of the sidelink reference signal. Figure 6 Step 6 of .19.3.1-1 describes the exchange of measurements. Figure 6 Step 7 in .19.3.1-1 describes the distance / position calculation. Figure 6 Step 8 in .19.3.1-1 involves sharing of distance / position values. Figure 6 .19.3.1-1, the process described in the previous embodiment related to the steps in 6.19.3-1-1 (such as for Figure 9Techniques for discovering, establishing positioning / ranging sessions, exchanging capabilities, configuring transmission of ranging reference signals, exchanging measurements, calculating distances / positions, and sharing distance / position values ​​are applicable. For example, the Device and Service Discovery Function (DSDF) relies on the PC5 discovery process, and therefore, the techniques of other embodiments are also applicable. The functionality of the SR5 service can run on different PC5 RATs (e.g., ProSe over NR, ProSe over LTE, V2X over NR, V2X over LTE).

[0386] According to some embodiments, for discovery, connection setup, and other ranging procedures, the device may reuse keys already configured for one or more of these PC5 RATs (e.g., DUIK, DUSK, DUCK for ProSe discovery), or may derive a new set of keys for ranging procedures over the SR5 reference point running over PC5 based on these already configured keys and one or more ranging-related parameters (e.g., ranging-specific ID or random number) (e.g., by using a key derivation function as defined in Annex B of 3GPP TS 33.220), or may be provisioned (e.g., by an authorized AUSF or NF responsible for managing ranging keys) with a new set of keys specific to ranging procedures over the SR5 reference point running over PC5. Ranging protocol messages may be protected (e.g., encrypted or integrity protected or scrambled) and may be encapsulated (e.g., as an extended LPP message) before being passed to the PC5 RAT.

[0387] According to some embodiments, PC5 / SR5 discovery keys are pre-configured before performing DSDF.

[0388] According to some embodiments, PC5 discovery keys or groupcast / multicast / broadcast credentials are pre-configured based on the (rough) UE location. This UE location can be provided / obtained by the LMF or by the UE. The PCF or other provisioning / management entity can retrieve / receive the location and restrict the provisioning of keys to only UEs within a certain distance from a reference point or anchor UE or target UE.

[0389] According to some embodiments, location (e.g., limiting the provision of keys to only UEs within a certain distance from a reference point) can also be generalized, for example, considering the same location in the future (taking into account the trajectory / movement / speed of the UE). For example, the CN may have information about the trajectory / movement / speed of a UE (e.g., a car) and predict where the UE will be at time t, so that the UE is configured with keys / parameters associated with the UE being at that location at that point in time.

[0390] According to some embodiments, UEs in a group (e.g., ranging constellation) are configured to perform discovery and / or connection establishment (e.g., DSDF-based) over multiple underlying RATs (e.g., V2X and ProSe). The UEs exchange their underlying RAT capabilities, and the UEs then agree on which RAT to use at a later stage. For example, assume that the UE wishes to determine its position with reference to some anchor UEs, which may be V2X or ProSe RATs. The UE (which may support both V2X and ProSe RATs) will then discover the anchor UEs, determining their type. For example, there may be a single V2X anchor UE and two ProSe anchor UEs, so that the UE will select these two ProSe anchor UEs and will perform the later stages using the ProSe RAT with the ProSe anchor UEs.

[0391] In a related variant, RAT selection is based on a configuration policy, which may, for example, determine that only RATs of a given type are to be used in a context (time, location, etc.), and therefore discovery (e.g., based on DSDF) should be based on that RAT discovery technique.

[0392] In a related variant, RAT selection is based on a configuration policy, eg, the configuration policy determines the selection of a RAT to be used for a later ranging / positioning procedure, which determines whether discovery should rely on multiple RATs or a single RAT.

[0393] According to some embodiments, a ranging protocol (eg, SPRF, GSSF) is used in a groupcast / broadcast mode, wherein the ranging protocol messages (eg, SPRF) are protected by one or more group keys.

[0394] According to some embodiments, one or more group keys are based on the discovery key in step 1, for example, derived from one or more discovery keys, for example, by a KDF (as defined in TS 33.220), and using the selected discovery key (e.g., DUIK) and, for example, the identity of the UE involved in the ranging / positioning session and / or a time-based counter as KDF input. This provides a simple and efficient method to derive group-based keys.

[0395] According to some embodiments, according to the policy configured on the UE (e.g., determining the group key needs to be done every T seconds or when performing a new discovery phase ( Figure 6 .19.3.1-1) to update the group key.

[0396] According to some embodiments, the ranging protocol / service (e.g., GSSF) is enhanced to manage one or more group keys by determining a group key UE owner (which may be a management entity) that is responsible for determining the group key (e.g., by randomly generating the key) and managing (e.g., storing, distributing, updating, revoking) the key.

[0397] According to some embodiments, a group key UE owner (e.g., a UE in a group (or a management entity)) may receive one or more root group keys from which such secondary (e.g., randomized) group keys may be derived from an application (e.g., via an NEF or GMLC) or from a core network function that manages and / or determines such a group of UEs (e.g., a set of anchor UEs that together form a constellation) or from a core network function that manages ranging (group) keys.

[0398] According to some embodiments, discovery keys or groupcast / multicast / broadcast credentials may be (pre-)configured based on a (rough) UE location which may be provided / obtained by the LMF or by the UE, whereby, for example, the PCF or other provisioning / management entity may restrict the provisioning of keys only to UEs within a certain distance from a reference point or anchor UE or target UE.

[0399] Depending on some scenarios, a first set of keys (e.g., discovery keys) and a second set of keys (e.g., groupcast / multicast / broadcast credentials / keys) may be (pre-)configured, and some of these keys may be preferably used, for example (e.g., the second set of keys, in this case, groupcast / multicast / broadcast credentials / keys) as provided by the NF (such as PKMF or LMF). However, if this preferred set of keys is not available, another set of keys may be used (the first set of keys may be used). This increases the security of the system because it ensures that the multicast / broadcast ranging messages can be protected, but it leads to the problem of determining which keys should be used to process / protect the secure multicast / broadcast messages. To address this issue:

[0400] According to some embodiments, the key set used to protect the multicast / broadcast message is indicated in the broadcast / multicast message, for example, a bit may be used to indicate whether the first set of keys or the second set of keys is used.

[0401] According to some embodiments, the key set used to protect multicast / broadcast messages includes a discovery key. A value associated with the discovery key (e.g., a relay service code, a hash / scrambled version of the relay service code, a KDF of one of the keys, etc.) is used as an identifier. This identifier can be rotated as in other examples to avoid privacy issues such as traceability.

[0402] According to some embodiments, the UEs may belong to different PLMNs. For example, the sending UE1 may belong to PLMN1 and the receiving UE2 may belong to PLMN2. For example, after obtaining the PKMF address from its PCF, the receiving UE2 may contact the PKMF1 associated with PLMN1 and may receive the corresponding key material. UE1 may also contact PKMF1. When UE1 sends its broadcast / multicast message, UE1 includes the identifier of PLMN1 in its broadcast / unicast message so that the receiving UE2 knows that the broadcast / multicast message is protected by the key associated with PKMF1. UE2 then cycles through its multicast / broadcast parameters associated with PLMN1. Similarly, in the case where there are multiple PKMFs per PLMN, UE1 includes the PKMF ID in the broadcast / multicast message and UE2 uses the PKMF ID to determine the set of multicast / broadcast keys to use.

[0403] In some embodiments, the PLMN ID or PKMF ID may extend the group ID.

[0404] It should be noted that the group ID is defined in TS23.586 [2], which indicates the ranging / sidelink positioning group to which the UE belongs and can be mapped to the target layer 2 ID. However, the group ID may be too short (8 bits) to accommodate the PLMN ID and / or PKMF ID, and it is not possible to allocate multiple group IDs that can be rotated. Therefore, the group ID should be much longer than 8 bits.

[0405] According to some embodiments, the group key UE owner may establish a secure unicast channel with each UE in the group, for example relying on a secure unicast link (e.g., based on SPRF running on PC5), and may distribute the group key to each group member using the secure channel.

[0406] According to some embodiments, the group key UE owner may be integrated in a management entity so that the management entity is responsible for the management of the group key.

[0407] According to some embodiments, the group key UE owner may not be integrated in a management entity that is responsible for responsibilities (e.g. authorization of UEs in ranging constellations), but not for management / distribution of group keys.

[0408] According to some embodiments, a ranging protocol / service (e.g., GSSF) or a UE in a group or a management entity may receive a request from an upper layer or application (e.g., via an NEF) or from a core network function that manages and / or determines such a group of UEs (e.g., a group of anchor UEs that together form a constellation) to, for example, add / remove group members or manage the group (e.g., merge two groups), in which case the group key used to protect group communications may be refreshed, for example, in a distributed manner (e.g., if the group key is derived from one or more discovery keys in the above-described embodiment variants) or in a centralized manner (e.g., if there is a group key UE owner).

[0409] According to some embodiments, the group key may be used to protect PC5 traffic or non-IP PDCP SDUs.

[0410] According to some embodiments, a group key may be used to protect one or more protocol interactions, such as:

[0411] Establish a ranging / positioning session.

[0412] Exchange UE capabilities.

[0413] Configuration of transmission and measurement.

[0414] Exchange measurements.

[0415] Swap position results.

[0416] According to some embodiments, the group key may be used for encryption, integrity protection or scrambling.

[0417] According to some embodiments, one or more group keys may be used to derive encryption keys and / or scrambling keys and / or integrity keys, eg by means of a KDF (such as described in Annex B of TS 33.220).

[0418] According to some embodiments, the encryption / scrambling / integrity key may be a session key that is refreshed, for example, before or after a ranging session.

[0419] According to some embodiments, the group key and / or the encryption key and / or the integrity key may be used in conjunction with the NR encryption algorithm (NEA) and / or the NR integrity algorithm (NIA).

[0420] According to some embodiments, the sent broadcast / multicast messages may be protected using an NEA / NIA direction parameter of, for example, 0 and / or a counter that is a UTC-based counter.

[0421] In accordance with some embodiments, the group key and / or encryption key may be used with a KDF (such as described in Annex B of TS 33.220) and input parameters such as a time-based counter to derive a pseudo-random sequence for encrypting and / or scrambling (e.g., XORing) a subset of fields of a message.

[0422] According to some embodiments, SPRF (GSSF) signaling can be used for control signaling between UEs to determine corresponding sidelink positioning and ranging operations, such as the channel used for sidelink positioning or ranging reference signals, the sequence and time slots in which each UE performs signal transmission and measurement. In particular, it is used to ensure that the UE is allocated a positioning or ranging reference signal so that it does not compromise the user's privacy, for example, as described above. Figure 9 Some of these actions may depend on the shared group key, as described in the relevant embodiments and / or by rotating it, and / or by randomizing it, for example, the assigned positioning signal (or an identifier determining the positioning signal) can be derived from the group key, for example, by a KDF (such as described in Annex B of TS 33.220).

[0423] According to some embodiments, the ranging constellation (e.g., TR 23700-86-120 Figure 6 .19.3.2-1) may rely on CN (e.g. LMF) to determine the distance / position. In this case, although the discovery (e.g. based on DSDF) may be open to a wide range of UEs (e.g. all UEs in a region), the anchor UE in the potential ranging constellation may request CN to check the authorization of specific UEs (e.g. UEs requiring ranging / positioning services and / or potential anchor UEs) after discovery. In this context, it is possible to extend Figure 6 .19.3.2-1 to request such authorization (e.g., by an anchor UE, which may be UE1 in the figure), and return the group key if the CN grants such authorization. For example, as an extension of the ranging procedure (e.g., after discovery), a UE (e.g., a target UE or an anchor UE) may request authorization of one or more other UEs from a core network function (such as UDM) or other management entity, and return the group key if such authorization is granted.

[0424] According to some embodiments, each participating UE in a potential ranging constellation (upon discovery) may prepare a message (e.g., a DCR-based message) that may include one or more of the following parameters: a UE identifier (PRUK ID or SUCI or Ranging ID), a service code, a key freshness parameter (such as K_NRP Freshness Parameter 1), or a time-based counter or the least significant bits of a MIC. The message prepared by each UE may be shared with the CN via the anchor UE as a "Key Request Message," which may contain the parameters. Some fields may be protected hop-by-hop between the UE and the anchor UE, e.g., the PRUK ID may be protected hop-by-hop as described in TS 33.503 clause 6.3.5, while some fields may involve end-to-end protection between the UE and the CN. For example, a key shared by the UE and the CN (e.g., K_AF derived via AKMA (TS 33.535)) may be used to calculate a MIC so that the CN (or an AF in the CN) can verify that the UE is who it claims to be. Inputs to the MIC calculation may include time-based counters or other parameters in the message. The MIC may be computed by a KDF (such as described in Annex B of TS 33.220) or the NR integrity algorithm, where the input key may be (derived from) K_AF.

[0425] When the anchor UE has to share this input from multiple UEs in the ranging constellation, the anchor UE may combine the fields of all received messages in a single "Key Request Message" towards the CN.

[0426] If there is an end-to-end protected field (eg, MIC), the CN (AF / NF) can verify whether the CN (AF / NF) is communicating with the correct UE (ie, authenticate the UE) through the shared key (eg, K_AF).

[0427] The CN can prepare a "key response message" which may contain keys, e.g., group keys sent securely to each authorized device (i.e., at most N-1 securely protected group keys). If the CN manages this key, this group key is included. The authorized UEs may need to be authenticated (e.g., based on MIC) and then authorized based on a policy that may be held by the PCF. The group key can be protected (end-to-end) using, for example, a protection key derived from a root secret associated with each UE (e.g., K_AUSF). For example, K_AF derived via AKMA according to TS 33.535 can be used. The "key response message" can also contain, for each authorized UE (<N-1), a key similar to K_NRP and a freshness parameter, e.g., K_NRP freshness parameter 2. For simplicity, the 5GC NFs and internal signaling are not described. Security procedures similar to those defined for 5G ProSe communication security for UE-to-network relay via the 5G ProSe layer 3 in TS33.503 [6] can be reused. The "key response message" can also include an explicit indication of which devices are authorized, i.e., the identities of the authorized UEs.

[0428] After receiving the "key response message", the anchor UE (e.g., Figure 6.UE1 in 3.2.1-1) knows which UEs are authorized by the CN to join the ranging / positioning session, for example by observing which UEs are receiving the protected group key. Next, the anchor UE distributes the received information (except K_NRP, if present) to the UEs via a single multicast message or via up to N-1 unicast messages. In the case of unicast messages, each unicast message includes the protected group key and / or K_NRP freshness parameter 2. Note that the K_NRP freshness parameter 2 is required if the group key is not end-to-end protected. Note that if the CN does not manage / provide the group key, the anchor UE must generate / manage / provide it. This may be received via a direct security mode command message. If the K_NRP freshness parameter 2 is available, this message can be protected using the K_NRP-ESS derived from the K_NRP and the freshness parameter. According to TS 33.536, the corresponding encryption and integrity keys can be derived from the K_NRP-SESS. If K_NRP-SESS based keys are used, the group key does not need to be protected end-to-end, but it can be protected hop-by-hop. After receiving a unicast message (e.g., a Direct Security Mode Command message) from an anchor UE, each UE receiving the message can determine the same key (e.g., based on K_NRP-SESS) and verify that the anchor UE is actually authorized to act as an anchor UE. The UE then sends a Direct Security Mode Complete to the anchor UE so that the anchor UE can actually verify that the UE is the UE it claims to be and is authorized. If the anchor UE only distributes the end-to-end protected group key, the UE can decrypt / integrity verify the group key. The advantage of not involving NRF related keys or freshness parameters is that fewer unicast messages are involved, thereby improving performance.

[0429] According to some embodiments related to the previous embodiment, the UE in the ranging constellation may send its request directly to the CN and may receive a response directly from the CN. In other words, the UE may not rely on the (n anchor point) UE to collect such messages (above the DCR message) and send them as a "key request message" to the CN, but the UE may directly send the request, for example, when the UE is in coverage.

[0430] According to some embodiments related to the previous one, the anchor UE may have been pre-configured with an authorization policy that allows determining which UEs are authorized.

[0431] According to some embodiments, the CN or anchor UE may distribute pairwise keys (e.g., instead of or next to the group key) to one or more members of the ranging constellation so that they can ensure secure communication between each pair of devices, respecting the privacy of each UE. For example, a target UE may receive its position calculated by an anchor UE (with local LMF functionality) that is protected by a pairwise key shared between the target UE and the anchor UE.

[0432] In accordance with some embodiments, instead of a pairwise key, the UE may receive key material allowing the derivation of a pairwise key, for example, a polynomial share derived from a symmetric bivariate polynomial f(x, y) of degree t, where the UE's polynomial share is obtained from f(x) by evaluating f(x, y) in x=ID, where ID is the identity of the UE.

[0433] According to some embodiments, the previous authorization step and group key establishment is performed after discovery and after obtaining the UE capabilities of the UE in the potential ranging constellation and before verifying the capabilities / requesting assistance data / requesting location information to the CN.

[0434] According to some embodiments, initial communications in the ranging constellation may initially be protected by one or more temporary group keys derived from, for example, a discovery key (e.g., an initial exchange of UE capabilities), and after the UE has been distributed and / or authorized by the CN, the temporary group keys are replaced by a session group key.

[0435] According to some embodiments, the session group key is not distributed and / or authorized by the CN, but is generated and distributed locally (i.e. in the ranging constellation) according to local user authorization. For example, the involved discovered UEs may prompt the user for a password / key request so that the user can enter the same password in all involved devices. This password / key can be used as a (root) group key or can be used in a password-authenticated key establishment protocol (e.g., the usage of which is shown for example in the case of UE-to-UE relay in TR 33.740, Sol#10) to establish a secure communication link between UEs, over which the group key can be securely exchanged. An advantage of this embodiment variant is that ranging can be performed even out of coverage when the devices lack pre-configured key material (e.g., group key) or the pre-configured key material has expired.

[0436] According to some embodiments, the CN may share a key associated with the UE in the ranging constellation (e.g., K_AF or a key derived therefrom or a key known to the UE) with the anchor UE so that the anchor UE can:

[0437] Manage group keys;

[0438] Authenticate the UE locally.

[0439] According to some embodiments, the group key or a key derived therefrom may be used to protect the transmission of measurements and / or the configuration of the exchange of measurements.

[0440] According to some embodiments, the UE is configured with a policy that determines at which layer security is provided. For example, PC5-U may be unprotected by default, a policy may request protection of PC5-U, or a policy may request protection at a higher layer (e.g., SR5 or application layer). For example, ranging-specific security may be implemented as part of the ranging protocol transmitted over an unsecured PC5-U.

[0441] According to some embodiments, the ranging / positioning protocol (eg, DSDF, GSSF, SPRF) is configured with a policy that determines the preferred type of security protection to use (eg, multicast or unicast based).

[0442] According to some embodiments, the security protection used is negotiated during the initial discovery phase (e.g., based on DSDF) or the ranging protocol connection establishment / configuration phase (e.g., based on SPRF) or during the initial authorization process with the CN, as shown in the above embodiments.

[0443] According to some embodiments related to the use of V2X RAT, V2X does not have the discovery phase of ProSe RAT, and therefore, the initial negotiation may not be protected in a similar manner and / or lack protection. Therefore, in the case of V2X RAT, the discovery process triggered by the ranging function on the SR5 interface may add security provisions to ensure security, for example, it may scramble certain fields before passing them to the V2X RAT (e.g., XOR with a pseudo-random sequence generated from a pre-configured key, and, for example, by a time-based counter of the key derivation function).

[0444] According to some embodiments, to ensure similar protection for V2X and ProSe RAT, security protection is provided by the ranging protocol, for example, by applying similar protection for ProSe messages (e.g., discovery messages), rather than by the underlying RAT.

[0445] According to some embodiments, since V2X lacks a discovery phase as in ProSe, the negotiation exchange may occur during the ranging process.

[0446] According to some embodiments, the identifier used by the UE may be rotated before or after the ranging procedure or in a periodic manner.

[0447] According to some embodiments, ranging parameters such as discovery parameters are time-limited, e.g., they are valid for a limited period of time, so that the UE can only participate in the ranging procedure if it has the appropriate parameters. These parameters may be discovery keys that are bound to a period of time, but they may also be identifiers, e.g., an identifier of the ranging procedure or of the UE.

[0448] According to some embodiments, to further protect the privacy of the target UE's location, an anchor UE in a group of UEs (e.g., a ranging constellation) that has calculated distance, angle, or location information related to the target UE can be configured to send the obtained distance, angle, or location information to the target UE using unicast communication rather than groupcast / broadcast, and can be configured to use a separate key to transmit the obtained distance, angle, or location information. This helps prevent sensitive location information from being leaked to other UEs (including other UEs in the group). This can be configured or provided as part of the target UE's privacy profile, which can be shared in advance with other UEs in the group of UEs, or can be included as part of the ranging / location request to the anchor UE.

[0449] According to some embodiments, a first UE (e.g., an anchor UE) may use a secure unicast connection to send certain messages (e.g., sending a derived distance, angle, or position to a central location database / server / service, after which only a target UE can retrieve or receive the derived distance, angle, or position information from the corresponding database / server / service), and may use a secure multicast message to send certain messages. This may be configured or provided as part of a privacy profile of a second UE (e.g., a target UE), which may be pre-shared with other UEs in the group of UEs (e.g., UEs in a ranging constellation), or may be included as part of a ranging / position request to a first UE (e.g., an anchor UE).

[0450] According to some embodiments, in order to prevent long-term tracking of the position of a first UE (e.g., a target UE (also within a group of UEs)), the first UE may include a temporary identifier in a ranging / position request (e.g., a mobile-initiated ranging / positioning request) to a second UE (e.g., an anchor UE), the temporary identifier to be used in the ranging process, for example, to be included in a report of measured or calculated distance, angle, or position information. The temporary identifier may be known only to the first / second UE (e.g., the target UE or the target UE), may be shared with a ranging service (e.g., LMF, RMF) in the core network or other management entity, or may be configured with one or more temporary identifiers to be used for the ranging process (e.g., based on a rotation or pseudo-randomization function).

[0451] According to some embodiments, a UE (eg, a target UE) may determine a new temporary identifier, or may request a new temporary identifier, or may receive a new temporary identifier each time it participates in a ranging procedure.

[0452] According to some embodiments, the ranging service (e.g., LMF, RMF) or other management entity may retain a mapping of temporary identities used for ranging to permanent identities used in the core network (e.g., SUPI, 5G-GUTI) to uniquely identify the corresponding target UE.

[0453] In accordance with some embodiments, each UE (e.g., an anchor UE, whose position is known or determined and / or whose position is to be used to calculate the position of a target UE) may use or be assigned a temporary identity, and a ranging service or other management entity may maintain a mapping of these temporary identities to permanent identities used in the core network to uniquely identify the corresponding anchor UE. Additionally or alternatively, the mapping is maintained in the UDM / UDR, and the ranging service or other management entity may request the permanent identities of the target UE and / or anchor UE when it is necessary to calculate the distance, angle, or position of the target UE (e.g., after receiving a ranging / position request from the target UE or after receiving a measurement request or calculated results related to the target UE from the anchor UE) and / or share the calculated distance, angle, or position information with, for example, the target UE or other core network services. In the case of a mobile-terminated ranging / position request or a network-induced ranging / position request, the ranging service (e.g., LMF, RMF) may include the temporary identities of the target UE and / or anchor UE in the configuration and / or the ranging / position request for the target UE and / or anchor UE. In this case, when receiving measurements / results, calculating or sharing calculated results, it can also link the temporary identity to the permanent identity using the mapping as described above.

[0454] In a related method, a UE may send a key request to the CN. The key request may include a group ID (e.g., constellation identifier) ​​and UE security capabilities. Based on the key request, the CN may check the supported security capabilities and provide parameters such as a group key, group member identifiers, group key identifier, algorithm identifier, etc. in a key response message. The group member identifier may also be randomly generated locally by the UE. The UE may then derive security keys. In particular, given the group key, the UE may derive a transport key, and given the transport key, it may derive encryption and integrity keys. The UE may then form a security message including parameters such as (group ID, group member IDs, group key ID, transport key ID, counter, payload, and MAC). A UE receiving a groupcast / multicast message may use the first four parameters to derive the transport key / integrity key / encryption key used to protect the message. Given the encryption key and / or integrity key, the receiving UE may then decrypt the message (e.g., payload) and verify the integrity / freshness of the message, for example, based on the counter and MAC.

[0455] This approach may still be subject to several considerations that are addressed by embodiments in this disclosure.

[0456] In a first consideration, a key request based on a group identifier may not be sufficient. One reason is that the group identifier may not be protected, so an eavesdropper (UE) that captures it may be able to send a request to the CN to retrieve the group key when the eavesdropper is not authorized.

[0457] Therefore, according to some embodiments, the above method may benefit from sending a key request as described in the above embodiments, for example, the key request includes a UE identifier and an authentication value so that the CN can verify whether the requesting UE is authorized.

[0458] According to some embodiments, the key request messages are exchanged over the PC8 interface defined in clause 5.2.5 of TS 33.503.

[0459] Therefore, according to some embodiments, the fields that may be subject to eavesdropping (e.g., the group ID) may be scrambled with a scrambling key. Generally, the entire message may also be scrambled. Therefore, the processing of a message when sending it may involve the following steps:

[0460] Calculate MIC;

[0461] Encrypt selected fields (e.g., payload and / or MIC);

[0462] Scrambling (selected message fields or the entire message).

[0463] The processing of the message by the receiving UE may involve the following steps:

[0464] Descrambling (scrambled message fields or the entire message);

[0465] Decryption keys / integrity keys are derived based on the descrambled fields.

[0466] decrypt(encrypted field (e.g. payload));

[0467] Verify message integrity (e.g., based on counter / MAC fields).

[0468] The scrambling key may be derived from the group key, for example based on a counter (eg a time-based counter).This scrambling key should not depend on other parameters such as the group member ID, as it is unknown.

[0469] In a second consideration, parameters such as Group ID or Group ID Members are static fields, so the UE may be tracked or it may give an indication about the type of ranging service it is using. Therefore:

[0470] According to some embodiments, this approach may benefit if message fields such as the group ID or group member ID are scrambled to mitigate tracking or privacy issues.

[0471] According to some embodiments, the message may rely on an identifier that is not static but temporary. For example, the broadcasted group ID may be rotated by deriving a temporary group ID identifier using, for example, a key derivation function or a hash function and, for example, a counter (e.g., a time-based counter) or a random number.

[0472] According to some embodiments, group member IDs are also rotated in a similar manner.

[0473] According to some embodiments, the group member ID is rotated implicitly by making the derivation of the group member ID dependent on the group ID itself (e.g., by using a KDF that takes as input the current temporary group ID and the fixed group member ID or the long-term UE identifier). If the group member ID depends on the group ID, the group member ID is rotated automatically.

[0474] In a third consideration, a UE can randomly select its group member ID. However, this may result in conflicts, i.e., two different UEs may use the same group member ID, which may lead to the situation where both UEs use the same key. If the group member ID is used in the ranging / positioning process itself, for example, if the group member ID is tied to a given location as in the case of a reference UE, this may also cause operational issues. The following procedure is used to handle this situation.

[0475] According to some embodiments, the UE monitors the group member IDs used by other UEs and verifies whether the message includes a group member ID that is equal to the group member ID of the receiving UE. If the receiving UE detects a conflict:

[0476] 1. If its group member ID is configured by the CN, the receiving UE may not change its own group member ID. The reason is that it is assumed that the CN will select the group member ID in a way that avoids conflicts. The receiving UE can send a request (broadcast) to the group member ID to update its group member ID.

[0477] 2. If the receiving UE's group member ID is generated by the UE itself, the receiving UE may decide to update its group member ID. The UE may then send an information message to inform other group members of the change.

[0478] According to some embodiments, group member identifiers may be divided into two ranges, with a first range for group member IDs assigned by the CN and a second range for self-assigned group member IDs. For example, a short range of identifiers may be reserved for CN-assigned identifiers, as the CN may assign these identifiers, for example, sequentially or in any other manner to avoid conflicts. For example, a longer range of identifiers may be reserved for self-assigned identifiers to avoid conflicts.

[0479] According to some embodiments, whether the group member ID is self-generated (or not self-generated) can be explicitly or implicitly indicated as part of the message. For example, the group member ID can have two lengths, which can be used to implicitly indicate the type of identifier used.

[0480] In yet another different approach, a key hierarchy can be defined for multicast / broadcast, for example:

[0481] Position Group Key (PGK): This key is provided to group members by the Key Management Function (KMF) in the CN. This key is used to derive the PTK of group members in the group.

[0482] Positioning Service Key (PTK): This key is bound to the group member. It is derived using the PGK based on the group ID, group member ID, and group key ID.

[0483] Position Session Key (PSessK): This key is generated by group members using their PTK based on the key generation time and a random number. This key is used to generate PSK, PEK, and PIK.

[0484] Position Scrambling Key (PSK): This key is generated using PSessK and is used for message privacy protection through scrambling.

[0485] Position Encryption Key (PEK): This key is generated using PSessK and is used for message encryption protection.

[0486] Position Integrity Key (PIK): This key is generated using PSessK and is used for message integrity protection.

[0487] The UE sending the message performs the following operations:

[0488] Construct a message, which includes one or more of a group ID, a group member ID, a group key ID, a key generation time, a random number, a message generation time, a message counter, a payload, and a MAC.

[0489] Select a valid PGK stored locally, use the PGK to generate / derive the PTK based on the group ID, group member ID, and group key ID, use the PTK to generate / derive the PSessK based on the current time and random number, and use the PSK to generate / derive the PEK, PSK, and PIK.

[0490] If message integrity protection is enabled, a MAC is calculated for the message, otherwise the MAC field is filled with all zeros or a random value. The integrity algorithm specified in Annex D of TS 33.501 [8] is used to calculate the MAC.

[0491] If privacy / confidentiality protection of the message is enabled, the payload and MAC are encrypted / scrambled. The encryption algorithm specified in Annex D of TS33.501 [8] is used for confidentiality protection.

[0492] The message receiving UE performs the following operations:

[0493] The group key ID carried in the message is used to select the locally stored PGK, and the PTK, PSessK, PEK, PSK, and PIK are calculated in the same way as the sending UE based on the parameters carried in the message.

[0494] If privacy / confidentiality protection of the message is enabled, the ciphertext is descrambled / decrypted.

[0495] If message integrity protection is enabled, integrity protection is verified by checking the MAC of the message.

[0496] According to some embodiments, the PTK and / or PSessK and / or PEK and / or PSK and / or PIK may be derived by a key derivation function (KDF), for example based on HMAC-SHA256, with a key and some personalization parameters as input (e.g., PTK=KDF(PGK, personalization parameters)), where the personalization parameters in the case of PTK may be the concatenation of the group ID, group member ID, and group key ID, and, for example, their respective lengths. The personalization parameters may also include a time value, such as a time counter based on UTC.

[0497] According to some procedures, for example, as described in Tdoc S3-233882, the input parameters of the KDF may be a group key identifier, a transport key identifier, or a group member ID. These parameters may also be exchanged in a broadcast / multicast message sent by the sending UE so that the receiving UE can calculate the same derived key. If a single device uses these identifiers, it is possible to ensure that the identifiers are unique. However, if multiple devices can be assigned / selected these identifiers, conflicts may occur. However, for example, when a group of devices performs ranging without network coverage, self-selection of identifiers (e.g., group member IDs) is a useful method. To solve this problem, the following embodiments may be applied:

[0498] According to some embodiments, a UE selecting its own identifier (e.g., a group member ID) may select from a different set or range of identifiers than the set or range of identifiers used by a network function (e.g., LMF or (SL)PKMF) to assign said identifiers. This has the advantage of reducing the chance of collisions.

[0499] According to some embodiments, the self-selected identifier is selected from a larger range than the identifiers assigned by the network function. This allows for reduced communication overhead and for distinguishing between messages from devices with self-selected identifiers (e.g., out of coverage) and those with assigned identifiers. For example, the self-selected identifier can be 8 bytes long, while the assigned identifier can be 3 bytes long. This can also reduce the chance that two devices with self-selected identifiers will select the same identifier. Therefore, these self-selected identifiers can be used as input to the KDF as in other embodiments.

[0500] According to some embodiments, identifiers may have a fixed portion (eg a prefix, such as the most significant bits) to determine whether they are assigned by the network or self-selected to reduce the chance of collisions between two sets of identifiers.

[0501] According to some procedures, for example, as described in Tdoc S3-234279, identifiers such as SLPTK IDs are UE-specific identifiers that are incremented each time a new SLPTK needs to be derived. This is similar to the counter value sent in a broadcast / multicast message. If the SLPTK is updated in this way, the use of these UE-specific incrementing counters can allow, for example, tracking of the UE. Therefore, to address this issue, in some embodiments that can be used independently or in combination with other embodiments, the SLPTK ID should be updated by applying a randomization function. For example, the UE can keep track of the SLPTK IDs used by using a bit mask of 2^b / 8=2^13=8kBytes (when b=16), i.e., the SLPTK ID is 16 bits long. The UE sets the bit mask to 0. The UE can generate a random number r, for example, by applying a function (e.g., KDF) on a random seed and a time counter. The UE can then check whether the bit r has already been used by checking whether it is zero or one. If r is zero, it sets bit r and uses r as the SLPTK ID. If r is one, it tries again by generating a new random value r and repeating the process. This allows the SLPTK ID to be changed in a non-sequential manner, thus avoiding tracking. Other functions can be used to update the SLPTK ID for the same purpose.

[0502] Similarly, in some embodiments, which can be used independently or in combination with other embodiments, the counter value according to TdocS3-233882 is device-specific, thus enabling tracking, and can be replaced with a time-based counter value derived from a UTC-based counter, as described in other embodiments. This time-based counter is used with the NIA or NEA algorithm defined in Annex D of TS 33.501. The counter input to the NIA or NEA algorithm is 32 bits long and must always be unique. If the time-based counter increments every 1 millisecond and the 32 bits are swapped, the time will overflow after 48 days. The timing can also vary; for example, it might increment every 10, 100, or 1000 milliseconds, depending on the configuration. The timing of each counter is updated and may depend on the maximum data rate and / or the maximum number of messages per second. This value is configurable.

[0503] In some embodiments, the NIA and NEA algorithms require further inputs, such as DIRECTION or BEARER, which may be set to configured / fixed values ​​or to variable values, such as the MSB of a time counter, such as a UTC-based counter.

[0504] Similarly, in some embodiments, which may be used independently or in combination with other embodiments, the LSBs of the time-based counter, e.g., the last 8 bits or 16 bits, may be swapped and a counter coordination procedure may be applied so that the receiving UE determines exactly the same time-based counter as the transmitting UE.

[0505] Similarly, in some embodiments, which can be used independently or in combination with other embodiments, a time-based counter can be used directly as a counter input to the NEA / NIA algorithm, or can be used in the most significant bits of the NEA / NIA algorithm. For example, if a broadcast / multicast message is 1024 AES (NEA0) blocks long, where an AES block is 128 bits long, the NEA counter can be set to the 22 LSBs of the time-based counter (concatenated with a 10-bit number set to 0, i.e., 00 00000000). If the time-based counter runs very quickly (e.g., it typically changes as fast as or faster than the number of messages per second per millisecond), then the MSB of the counter will always be unique when passed to the NEA / NIA. The LSBs of the counter are initialized to zero, and the number of LSBs set to zero should be sufficient to cover the length of the message measured in blocks in the NEA / NIA algorithm.

[0506] In some embodiments, a broadcast / multicast message may include a time value, such as a time counter. A receiving UE may check for freshness by verifying that the time counter is within a time window from its own time, for example, that the absolute value of the difference between the received time counter from the transmitting device and the time counter from the receiving device is not greater than a threshold. The time value included in the broadcast / multicast message may also be used as an input parameter in key derivation (e.g., SLPTK key derivation).

[0507] In another embodiment, the receiving UE may check the freshness of the broadcast / multicast message based on a bit value associated with a time counter, whereby the receiving UE performs an XOR operation between the bit value of the received time counter and the bit value of its own timer counter, where a threshold is determined by the position of the MSB set to 1, such that if the result of the XOR operation produces a bit value below the threshold, the message is considered fresh / valid.

[0508] According to some embodiments, PSessK may only depend on a random number or time.

[0509] According to some embodiments, the time value included in the message is not the complete time value, but only the least significant bits of the time value (eg, a UTC-based value).

[0510] According to some embodiments applicable to the above methods and other methods, the security protections (e.g., encryption and / or integrity protection and / or privacy protection (e.g., scrambling)) to be applied are determined by policies configured in the device performing the broadcast / multicast. When a UE sends or receives a message, the UE applies the configured policies associated with the group ID and / or device ID and / or key ID in the message. For example, within a group, some devices may require confidentiality, while others may not.

[0511] In a further consideration applicable to the above methods and other methods, the transmission of the group ID and / or device ID and / or key ID may pose a privacy risk (e.g., allowing tracking), and therefore, it can be protected as in other embodiments, for example, by scrambling or rotating it. This is a feature that can be used in combination with other embodiments or independently. For example, the transmitting UE can scramble the identifier before transmission, for example using a scrambling key that can be derived from a PSessK (e.g., PSK). The scrambling sequence may only be applicable to those privacy-sensitive parameters. For example, the scrambling sequence can be generated by using a KDF or NEA algorithm that takes as input the scrambling key and the time and / or a random number (e.g., a random number in the message). For example, the receiving UE can attempt to descramble the received scrambled field and check whether the descrambled value corresponds to the ID linked to the scrambling key used (e.g., the group ID). If the descrambled value corresponds, the receiving UE can further process the message. Similar logic applies if the field is not scrambled, but if a pseudo-identifier is used (e.g., a pseudo-identifier that is somehow derived from one of the privacy-sensitive identifiers).

[0512] A further consideration applicable to the above and other methods is that integrity protection may not always be required. If it is not required, the UE can set the MIC field to a predefined value, such as all zeros, by sending a multicast / broadcast value. However, this behavior may reveal whether the message is integrity protected. This is a problem because it can allow a passive attacker to more quickly determine which messages can be replayed. To address this issue, one or more of the following embodiments may be applied.

[0513] According to some embodiments, which can be combined with or used independently of other embodiments, the MIC used to protect ranging information in multicast / broadcast is always encrypted, even if the rest of the message is not encrypted (e.g., if the policy does not require confidentiality protection for multicast / broadcast messages).

[0514] According to some embodiments, which may be combined with other embodiments or used independently, if the policy does not require integrity protection of multicast / broadcast messages, the MIC for protecting ranging information in the multicast / broadcast is set to a random value.

[0515] According to some embodiments, the MIC is verified based on a configuration policy or integrity protection indication (e.g., a field that may be protected by confidentiality) in the message. If the configuration policy requires integrity protection, the MIC is verified; if integrity protection is not required, the MIC is not verified.

[0516] According to some embodiments, which can be combined with other embodiments or used independently, the multicast / broadcast includes an integrity protection indication field that indicates whether the message is integrity protected.

[0517] In yet another different approach, the LMF may manage multicast / broadcast encryption keys for use in one or more tracking areas, registration areas, or cells. The LMF may share these keys with the AMF. Specifically, the LMF may share one or more sets, each of which may include an encryption key, an encryption key identifier, a validity period, a set of applicable tracking areas, registration areas, or cell IDs, and a set of applicable types of positioning / ranging broadcast / multicast data. The AMF may store these sets. A UE (e.g., a target or reference UE) may use a Registration Request in accordance with TS 23.502 to obtain broadcast / multicast encryption keys for positioning / ranging. This request may include an indication of the required broadcast / multicast encryption keys. If authorized to receive encrypted positioning / ranging broadcast data, the AMF includes one or more positioning broadcast keys applicable to the current tracking area, registration area, or cell in the Registration Accept. Given the provided keys, the reference UE may transmit encrypted positioning / ranging multicast or broadcast data. Once the encryption key's validity period begins, and if the UE is currently in an applicable tracking area, registration area, or cell, the target UE may begin using the broadcast / multicast encryption keys for positioning / ranging. When a UE enters a tracking area, registration area or cell that is not applicable to the broadcast / multicast encryption key, it may stop using the broadcast / multicast key for positioning / ranging. When the validity period of the SL positioning broadcast / multicast encryption key expires, the UE should stop using and delete the broadcast / multicast encryption key used for positioning / ranging. In a related method designed to protect, for example, out-of-coverage multicast / broadcast sidelink positioning data, multiple UEs (e.g., target UE, reference UE and server UE) may be able to communicate with each other. The server UE may initially generate some encryption keys, and for each key, it may include metadata, including the key value, key identifier, validity period, a set of applicable tracking areas or registration areas or cell IDs, and a set of applicable types of SL positioning broadcast / multicast data. The UE (e.g., target UE or reference UE) may send a sidelink positioning encryption key request to the server UE. This may be part of the normal PC5 signaling process or part of the ranging protocol. The UE may include an indication of the required encryption key. The server UE may then return the requested key and related metadata. The UE may then use the encryption key to protect the group communication.

[0518] The first consideration among these methods is that they only deal with encryption keys. Even if the encryption keys can be used to protect the privacy of the message, the message may still be modified.

[0519] Therefore, according to some embodiments, the CN (e.g., LMF and / or AMF and / or other NF) should also process integrity keys or group keys for providing integrity protection, as described in other embodiments in this application.

[0520] The second consideration in these methods is the process of performing authorization at the AMF, i.e., whether the UE is authorized to receive certain keys.

[0521] According to some embodiments, the AMF can not only receive one or more sets from the LMF, but also receive the identities of the UEs authorized / subscribed to the broadcast / multicast data. Each set includes an encryption key, an encryption key identifier, a validity period, a set of applicable tracking areas or registration areas or cell IDs, and a set of applicable types of positioning / ranging broadcast / multicast data.

[0522] According to some embodiments, the AMF can request the subscription data from the AUSF / UDM / UDR

[0523] The third consideration in these methods relates to the UE behavior when the validity period of the key is about to expire. Since the sending UE may use an old key, and when receiving a message (e.g., containing measurements) from the sending UE, the receiving UE may use a new key, making the decrypted payload (e.g., measurements) incorrect / junk. This effect is even greater because the message is only encrypted, so the decrypted data will be considered valid and further processed. For example, when the key is bound to a tracking area (or registration area or cell) and the UE is moving from one tracking area (or registration area or cell) to another adjacent tracking area (or registration area or cell), a similar problem to this timing boundary also occurs at the location boundary.

[0524] Therefore, according to some embodiments, the sending UE and the receiving UE should use integrity checks (e.g., MIC) to ensure that the data is decrypted with the correct key. This serves as an implicit verification of using the correct key.

[0525] Therefore, according to some embodiments, the message can include an identifier of the key used for encryption. This serves as an explicit verification of the key used. The receiving UE should use the said key.

[0526] According to some embodiments, the receiving UE can (attempt to) use the current and old encryption / integrity keys to process incoming messages. Note that this method also allows keys that are valid simultaneously for at least some period of time. For example, K1 can be valid from T0 to T2, K2 can be valid from T1 to T3, and T0 < T1 < T2 < T3. This ensures that broadcast messages are correctly processed even within the key validity boundaries. A similar method can be used for tracking areas (or registration areas or cells), where a UE moving to a second tracking area (or registration area or cell) can use, for example, the key for decrypting the old tracking area (or registration area or cell) and the key for the new tracking area (or registration area or cell).

[0527] According to some embodiments related to the previous embodiment, the CN (e.g., AMF) may deliver to the UE not only the group key associated with the current validity period or tracking area (or registration area or cell), but also the group key associated with the subsequent validity period and / or adjacent tracking area (or registration area or cell). This embodiment, combined with the previous embodiment, aims to improve (ranging / positioning) service continuity.

[0528] In the fourth consideration, the LMF needs information about the tracking area (or registration area or cell) in order to provide meaningful key configuration to the AMF.

[0529] Therefore, according to some embodiments, the LMF may send a request to the AMF to retrieve such configuration.

[0530] According to some embodiments, the key management function can be at the AMF, so that the LMF only indicates the requirements (e.g., keys per tracking area / given area, etc.), and the AMF is responsible for key management (generation, distribution, deletion, etc.). This provides a better division of responsibilities between the AMF and LMF.

[0531] In the fifth consideration, the LMF handles sets of key material, where each set may include an encryption key value, an encryption key identifier, a validity period, a set of applicable tracking areas (or registration areas or cells), and a set of applicable types of SL positioning broadcast / multicast data. This can be a problem because many key sets may be required (per tracking area (or registration area or cell) and service).

[0532] According to some embodiments, keys are linked to locations, and keys are linked to services. A UE subscribed to services A and B then receives keys KA and KB, and if the UE is in area 1 and area 2, the UE receives K1 and K2. Then, when the UE uses service A in area 1, the UE can calculate the group key K=F(K1, K2), i.e., K is a function F() of K1 and K2, such as a hash function, or HMAC or KDF. This approach allows for simpler key management because location-related keys can be managed based only on location information, while service-related keys are managed only based on subscribed services. This approach allows for stronger security because even if a certain type of key (e.g., location 1 and service A) is leaked, a UE of a second service at the same location 1 can still communicate in a secure manner.

[0533] According to some embodiments, the broadcast message is not integrity protected by a message integrity code, but the encryption covers at least the fields known to all UEs in the group (particularly the receiving UE). If the receiving UE does not use the correct decryption key, the known fields are incorrectly decrypted, and the receiving UE knows that the message was not correctly decrypted and that the wrong decryption key was used. For example, the sending UE may include fields such as a group ID in the message. The sending UE can, for example, encrypt both the payload and the group ID by using an encryption key (e.g., derived from the group key) and the NEA algorithm. The receiving UE may not know to which group the broadcast / multicast message belongs, and therefore the receiving UE may need to try multiple (decryption) keys. If the decryption group ID field in the received message matches the group ID linked to the decryption key used in the decryption, the UE knows that the correct decryption key has been selected. This method may have the advantage of being more lightweight (because there is no need to calculate or send a MIC). This embodiment variant can be used to improve the above method.

[0534] In some cases, a UE may leave a group, or may lose authorization to be part of the group. When this happens, the following embodiments may apply.

[0535] According to some embodiments, the entity handling / managing the group keys may send a group key update message to all group members that are still authorized. The group key update message may need to update any keys known to UEs that have left the group. The entity handling the group keys may be notified / may query the entity managing the group if / when group membership changes so that the key update message can be sent as soon as possible. The key update message may include conditions for performing the key update, such as that the smallest UE in the group (e.g., the smallest reference UE and the smallest target UE) has received the new group key so that ranging service operation is not compromised.

[0536] According to some embodiments, the group key may be linked to a short lifetime so that no active key update process is required since a compromised group key expires quickly. However, this may require setting / configuring a schedule in the UE / group key owner to ensure timely delivery of the new group key before the old one expires.

[0537] According to some embodiments, the UE may be configured with a policy or receive a message (e.g. from the LMF) that determines whether certain SL positioning data (e.g. SL positioning assistance information) is to be sent using multicast / broadcast on the sidelink. Different policies may be configured for different types of devices or scenarios, e.g. an anchor UE that needs to broadcast SL positioning assistance information to other anchor UEs and / or target UEs within network coverage may be configured differently from a target UE that needs to broadcast SL positioning assistance data to a group of anchor UEs, and may be configured differently from a ProSe UE that only needs to "forward" the received information to the network or to a UE-to-UE relay node.

[0538] The received policy or message used to determine whether to send certain SL positioning data using multicast / broadcast on the sidelink may include:

[0539] The context used to broadcast data, e.g.

[0540] If the UE is aware of other UEs that are out of coverage, the UE is required to perform broadcast / multicast; or

[0541] Broadcasting / multicasting may be allowed / required only at certain times (e.g., peak hours) or in certain locations / areas; or

[0542] Broadcast / multicast may be allowed only when the network load (e.g. the number of UEs) is above a threshold, or

[0543] Broadcasting / multicasting to a UE may be allowed only if the UE receiving the message including the SL positioning data has not yet seen / received the message and / or its information (e.g., SL positioning data) (re)broadcasted / (re)sent (e.g., at least once or at least a minimum number of times (e.g., N)) via the local interface (sidelink / PC5).

[0544] Broadcasting / multicasting to a UE (UE1) may only be allowed if the UE receiving the message including the SL positioning data knows other UEs (e.g., UE2, out-of-coverage UEs) that are interested in / registered to the data included in the received message. For example, if UE2 has indicated to UE1 that it is interested in the positioning / ranging assistance data, UE1 will broadcast / distribute the received SL positioning data.

[0545] Broadcast / multicast may be allowed only when the UE has received discovery messages from a minimum number of other UEs.

[0546] Broadcast / multicast may be allowed only if the message has not been forwarded a maximum number of times (eg, based on the number of hops between the UE and the network).

[0547] Broadcast / multicast may be allowed only when the UE acts as a specific type of relay (e.g., Layer 2 ProSe UE to network relay, Layer 3 ProSe UE to network relay, an in-coverage anchor UE forwarding messages (e.g., LPP messages) to / from the network on behalf of an out-of-coverage target UE).

[0548] The role of the UE for broadcasting / multicasting data, for example, only anchor UE or reference UE may be allowed to perform broadcast / group broadcast, or even only UE with this specific broadcast / multicast role (e.g., reference UE) may be allowed; for example, only devices with relay capabilities (such as UE-to-network relay or UE-to-UE relay).

[0549] A security policy that determines how broadcast messages are protected.

[0550] Which subset of the data is received (e.g., only SL positioning assistance data is received as part of the SL positioning data that is intended for UEs other than the UE receiving the data (e.g., indicated by a different (set of) device IDs)).

[0551] According to some embodiments of the present invention, TS 33.533-100 includes procedures for secure multicast and broadcast in clause 6.4.4. However, these procedures still have many problems that need to be solved:

[0552] - First, clause 6.4.2 in TS 33.533-100 includes the following requirement: "The 5G system shall support methods to provide confidentiality, integrity, and anti-replay protection of SL positioning signaling during broadcast / multicast communications used for ranging / SL positioning." However, the procedures in clause 6.4.4 do not provide a method for anti-replay protection.

[0553] -Second, clause 6.4.4 states that if the SLPKMF does not assign a group member ID, then the group member ID can be randomly generated. Self-generated IDs have the advantage of being able to rotate them to prevent linking / tracking by attackers. However, if the ID is short, two UEs may choose the same ID.

[0554] - Third, the use of a constant or device-specific SLPGKID allows linking of UEs. Similarly, the use of a constant or device-specific SLPTKID, a counter allows linking of messages and tracking of specific UEs.

[0555] - It may be necessary to swap the time counter to ensure freshness. For performance reasons, only the b least significant bits can be swapped instead of swapping the entire time counter. However, this requires that all UEs can recover the time counter of the sending UE.

[0556] The object of the present invention is to solve the above-mentioned disadvantages by means of one or more of the embodiment variants of the present invention and / or the following methods.

[0557] In the first method, a UE (e.g., a transmitting / receiving UE) is configured with a freshness time threshold. This is a parameter used by the UE to determine whether a message and / or key is still fresh. This parameter can be configured in step 1b of clause 6.4.4 of TS 33.533-100. This parameter can be related to the maximum time difference allowed between different UE times.

[0558] In the second method, the sending UE selects security parameters based on the validity time of the security parameters. For example, the sending UE must select valid security parameters (i.e., SLPGK, SLPGK ID, etc.) based on the validity time of the security parameters, for example, the sending UE must check that they have not expired based on the validity time and / or its local time and / or freshness time threshold, or select the paramet...

Claims

1. An apparatus for obtaining a distance or location estimate of a target mobile device (10) within a wireless network, wherein: The device is suitable for: - requesting ranging or positioning services from a ranging constellation (50) formed by one or more anchor devices (14) with ranging capabilities of the wireless network via a ranging or positioning request; - receiving at least one multicast / broadcast message via the PC5 communication interface; - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message, The multicast / broadcast message includes: - encrypted data protecting said information contained in said multicast / broadcast message, - a group member ID assigned by a management entity or randomly generated by the sender of said multicast / broadcast message, and - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

2. The device according to claim 1, wherein The multicast / broadcast message includes a counter, such as a time-based counter, as an input to an encryption algorithm and / or an integrity algorithm.

3. The device according to any one of the preceding claims, wherein The apparatus is adapted to determine, based on the group member ID length, whether the group member ID is generated by the management entity or by the sender.

4. The device according to any one of the preceding claims, wherein If the selected integrity algorithm is the NULL algorithm, the MIC is not set to zero.

5. The device according to any one of the preceding claims, wherein The device is adapted to verify message freshness by checking the counter.

6. A device according to any one of the preceding claims, wherein The message includes a randomized or scrambled device-specific identifier.

7. An apparatus for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The device is suitable for: requesting ranging or positioning services from a positioning constellation (60) formed by one or more anchor devices (14) and access devices (20) of the wireless network having ranging capabilities via a ranging or positioning request; receiving one or more multicast / broadcast messages from an access device; A distance or position estimation or ranging measurement is performed based on information in the at least one responsive multicast / broadcast message.

8. A device according to any one of the preceding claims, wherein The ranging or positioning request includes one or more of the following: The ranging and positioning capabilities of the device, (Ranging) Group ID, The type of service requested (ranging / positioning), The requested reply type (unicast / broadcast / ...), Identification / authentication / authorization credentials, instructions to emergency services, Preference for NULL-safe algorithms.

9. The device according to any one of the preceding claims, wherein The apparatus is adapted to receive at least one configuration message having configuration parameters for receiving the one or more multicast / broadcast messages via the access device, wherein the configuration message is a ranging service confirmation, the ranging service confirmation including configuration parameters such as one or more multicast / broadcast keys or a selected security algorithm, or security parameters for protecting multicast / broadcast messages in the RAN and in the ranging constellation.

10. The device according to claim 7 or 9, wherein: The multicast / broadcast message is an MBS message or an RRC broadcast message or an SIB.

11. The device according to any one of the preceding claims, wherein The multicast / broadcast message includes an indication of ranging positioning capabilities (eg, physical layer capabilities) or assistance data or cryptographic values ​​(eg, keys, authorization tokens, etc.) of the anchor device and / or devices in the positioning constellation.

12. The device according to any one of the preceding claims, wherein The multicast / broadcast message is protected by one or more of encryption, scrambling, and integrity protection, and wherein the apparatus is adapted to process the protected multicast / broadcast message to successfully decode the multicast / broadcast message.

13. The apparatus according to claim 7, 9, 11 or 12, wherein: The key used to protect the multicast / broadcast message is used to securely transmit a seed or as a seed to obtain a group key for subsequent multicast / broadcast communications in the ranging constellation.

14. The apparatus of claim 7, 9, 11, 12 or 13, wherein: The device is suitable for: - obtaining a counter C1 by combining a value C0 received in a protected message or derived from all or part of another counter and / or a value D0 received in said broadcast message and / or a data segment counter, - obtaining a decryption key and / or an integrity key by applying a key derivation function to a preconfigured key and said counter C1, - applying an encryption algorithm (e.g. AES or NEA in counter mode) together with said counter C1 and decryption using said key to decrypt said data in said broadcast message, - applying the counter C1 and the integrity key to calculate the MIC by means of the KDF or NIA algorithm and verifying the integrity of the received response broadcast message, - If the integrity verification is successful, the decrypted data is passed to the upper layer.

15. The device according to claim 7, 9, 11, 12, 13 or 14, wherein The ranging service is bound to the MBS service.

16. An apparatus for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The device is suitable for: - receiving a ranging or positioning request for a ranging or positioning service from a requesting device, the ranging or positioning service involving a ranging constellation (50) formed by one or more anchor devices (14) of the wireless network having ranging capabilities; - Send at least one multicast / broadcast message via the PC5 communication interface; - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message, The multicast / broadcast message includes: - encrypted data protecting said information contained in said multicast / broadcast message, - a group member ID assigned by a management entity or randomly generated by said means of said multicast / broadcast message, and - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

17. A method for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method comprises: - requesting ranging or positioning services from a ranging constellation (50) formed by one or more anchor devices (14) with ranging capabilities of the wireless network via a ranging or positioning request; - receiving at least one multicast / broadcast message via the PC5 communication interface; - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message, The multicast / broadcast message includes: - encrypted data protecting said information contained in said multicast / broadcast message, - a group member ID assigned by a management entity or randomly generated by the sender of said multicast / broadcast message, and - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

18. A method for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method comprises: - receiving a ranging or positioning request for a ranging or positioning service from a ranging constellation (50) formed by one or more anchor devices (14) of the wireless network having ranging capabilities; - Send at least one multicast / broadcast message via the PC5 communication interface; - performing a distance or position estimation or ranging measurement based on the information in the at least one multicast / broadcast message, The multicast / broadcast message includes: - encrypted data protecting said information contained in said multicast / broadcast message, - a group member ID assigned by a management entity or randomly generated by said means of said multicast / broadcast message, and - If the selected integrity algorithm is the NULL algorithm, set to the MIC of a random number.

19. A method for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method comprises: - requesting ranging services from a positioning constellation (60) formed by one or more anchor devices (14) and access devices (20) of the wireless network having ranging capabilities; - receiving at least one multicast / broadcast message from an access device; - Performing distance or position estimation or ranging measurements based on at least one multicast / broadcast message.

20. An apparatus in an access device for obtaining a distance or location estimate of a target mobile device (10) within a wireless network, wherein: The device is suitable for: receiving a ranging or positioning request for a ranging or positioning service involving a positioning constellation (60) formed by one or more ranging-capable anchor devices (14) and access devices (20) of the wireless network; Send one or more multicast / broadcast messages; A distance or position estimation or ranging measurement is performed based on information in the at least one responsive multicast / broadcast message.

21. A method for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method includes accessing the device to perform the following operations: - receiving a request for a ranging service from a requesting device, the ranging service relating to a positioning constellation (60) formed by one or more anchor devices (14) and access devices (20) of the wireless network having ranging capabilities; - Send at least one multicast / broadcast message; - Performing distance or position estimation or ranging measurements based on information contained in said multicast / broadcast message.

22. An apparatus for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The apparatus is adapted to be provided with a ranging positioning signal identifier SL-PRS sequence ID by a management entity, and the apparatus is configured to: use the SL-PRS sequence ID to generate a ranging positioning signal and broadcast the ranging positioning signal through a PC5 interface, and use the ranging positioning signal to perform distance or position estimation or ranging measurement.

23. The device according to claim 22, wherein The apparatus is provided with a ranging positioning signal identifier SL-PRS sequence ID allocated to the anchor device with ranging capability by an anchor device with ranging capability or by a management entity, and the apparatus performs distance or position estimation or ranging measurement using a received ranging positioning signal determined by the provided SL-PRS sequence ID.

24. A method for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method comprises: - the target mobile device receives a ranging positioning signal identifier SL-PRS sequence ID from a management entity, and The target mobile device generates a ranging positioning signal using the SL-PRS sequence ID and broadcasts the ranging positioning signal through a PC5 interface, and performs distance or position estimation or ranging measurement using the ranging positioning signal.

25. An apparatus for assisting in obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The device is suitable for: - receiving a first message containing positioning / ranging assistance data from an access device; - resending at least part of said first message via the PC5 interface.

26. The device according to claim 25, wherein The apparatus is adapted to resend the first message as a local multicast / broadcast message via the PC5 interface.

27. An apparatus according to claim 25 or 26, adapted to resend the first message as a local multicast / broadcast message via the PC5 interface if permitted by a policy configured in the apparatus or an indication in the received message.

28. The apparatus of claim 25, 26 or 27, wherein The first message containing positioning / ranging assistance data from the access device is a multicast / broadcast message.

29. The apparatus of claim 25, 26, 27 or 28, wherein The retransmission of the first message applies to all or part of the first message, and whereby the policy or directive maps all or part of the first message to a local identifier.

30. The apparatus of claim 26, 27, 28 or 29, wherein The apparatus is further configured to perform security processing on the first message before resending, wherein the security processing can involve one or more of the following: Check the MIC on the received data, encrypting the data, Calculate the MIC and append it to the sent (multicast / broadcast) message, Scramble (a portion of) the (multicast / broadcast) message being sent, If the device determines that it is involved in emergency services, it sends an unprotected SIB, decrypting the data and determining whether the data also relates to the device itself, The data is decrypted and a determination is made as to whether the device needs to initiate a ranging / sidelink positioning procedure.

31. The device according to any one of claims 25 to 30, wherein The message from the access device is a positioning SIB.

32. The device according to any one of claims 25 to 31, wherein The device is suitable for: - receiving, by PC 5, a second message from the wireless communication device, the second message including one or more of the following data elements: oKey material identifier, oRequests for ranging / positioning assistance data, o instructions to emergency services, o Preference for NULL-safe algorithms; - storing a binding between an identifier of the wireless communication device and one or more of the received data elements; - issuing or forwarding a request containing one or more of the received data elements to the network; - resending all or part of the first message based on the binding.

33. A method for assisting in obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method includes the wireless device performing the following operations: - receiving a first message containing positioning / ranging assistance data from an access device; - resending at least part of said first message via the PC5 interface.

34. An apparatus for assisting in obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The device is suitable for: operating as an anchor UE that knows or is capable of determining its own position with a first level of accuracy; receiving a message from a second wireless device, the message including a request to obtain and / or share its location, wherein the request is a message via the PC5 interface; Sending a first message to the second wireless device and / or sending a second message to a location service in a core network, wherein: The first message includes one or more of the following: Error message, the position of the device with a second level of accuracy, the second level of accuracy being lower than the first level of accuracy, the location of the apparatus being protected with different security credentials when sharing the location information with the second wireless device and / or the third wireless device than when sharing the location information with a location service, measurements of the apparatus secured firstly with a first set of security credentials shared with a location service in the core network and / or measurements of the apparatus secured with a second set of security credentials shared with the second wireless device; And the second message includes: whether to share the location of the apparatus with the second wireless device and / or the third wireless device.

35. The apparatus of claim 34, wherein: The second wireless device is the target mobile device (10) or a location service agent, or the third wireless device is the target mobile device (10) or a location service agent.

36. The apparatus according to claim 34 or 35, wherein The device is adapted to determine the content of the first message and the second message based on a privacy profile or privacy configuration or privacy preferences of the device and / or based on a confirmation dialog with a user of the device.

37. The device according to any one of claims 35-36, wherein The request includes one or more of the following: • an indication that the request relates to ranging / sidelink positioning services; • an indication of the type of ranging / sidelink procedure; The type of ranging / sidelink position-related information requested; • an identifier of the second wireless device and / or third wireless device with which the location information is to be shared; • A description of the second wireless device and / or third wireless device with which the location information is to be shared.

38. The device according to any one of claims 35 to 37, wherein The device determines the content of the first message based on whether the device encounters one or more of the following situations / states: - the anchor UE disables its role as a positioning UE; - The location of the anchor UE is currently unavailable (e.g., lost location fix, etc.); - the time since the location was last determined or the time since the UE last had a location fix is ​​greater than a certain duration, or greater than a maximum duration as requested / indicated by the requesting target UE, location service agent or LMF; - the accuracy of the location information becomes lower than a minimum threshold or lower than the accuracy requested / indicated by the requesting target UE, location service agent or LMF; or - The anchor UE is moving above a certain minimum speed.

39. A method for obtaining a range or location estimate of a target mobile device (10) within a wireless network, wherein: The method comprises: receiving, by a first wireless device operating as an anchor UE that knows or is capable of determining its own location with a first level of accuracy, a message from a second wireless device, the message comprising a request to obtain and / or share its location, and the request being a message exchanged over a PC5 interface; Sending a first message to the second wireless device and / or sending a second message to a location service in a core network, wherein: The first message includes one or more of the following: Error message, the position of the device with a second level of accuracy, the second level of accuracy being lower than the first level of accuracy, the location of the apparatus being protected with different security credentials when sharing the location information with the second wireless device and / or the third wireless device than when sharing the location information with a location service, And the second message includes: An indication of whether the location of the apparatus is to be shared with the second wireless device and / or the third wireless device.

40. A method for determining a transmission mode of a system information message, wherein: The method comprises an apparatus for performing the following steps: Determine the need for a collection of system information messages, Determining, for each system information message of the required set, a corresponding broadcast state indicating a transmission mode of the system information message from a network entity, wherein determining the transmission mode comprises: - determining whether an advanced information element is stored in the device or has been received by the device, and - after determining that an advanced information set is stored in the device or has been received by the device, determining a corresponding transmission mode of the system information message in the legacy information element and / or in the advanced information element.

41. The method according to claim 40, wherein The advanced information element includes the schedulingInfoList2 information element within the si-SchedulingInfo-v1700 information element.

42. The method according to any one of claims 40-41, wherein The system information message is at least one of a system information block or a posSIB.

43. The method according to any one of claims 40 to 42, wherein: The transmission mode is at least one of the following: -Regular broadcasts, - Request and broadcast on demand, or - Dedicated requests and broadcasts.

44. The method according to any one of claims 40 to 43, wherein for posSIB acquisition, - the transmission mode is determined by the posSI-BroadcastStatus field in the legacy information element corresponding to the posSchedulingInfoList in posSI-SchedulingInfo, or - The transmission mode is determined by the si-BroadcastStatus field in the advanced information element, which corresponds to schedulingInfoList2 in si-SchedulingInfo-v1700.

45. The method according to any one of claims 40 to 43, for SIB acquisition, wherein: - the transmission mode is determined by the si-BroadcastStatus field in the legacy information element corresponding to the schedulingInfoList in si-SchedulingInfo, or - The transmission mode is determined by the si-BroadcastStatus field in the advanced information element, which corresponds to schedulingInfoList2 in si-SchedulingInfo-v1700.

46. ​​The method according to any one of claims 40 to 44, wherein If the transfer mode is set to: - Broadcast, then obtain the system information message according to the content defined in clause 5.2.2.3.2 of TS 38.331, - non-broadcast, and the device is in RRC_IDLE or RRC_INACTIVE state, initiates transmission of the RRCSystemInfoRequest message according to 5.2.2.3.3a and 5.2.2.3.4, and - Non-broadcast, and the device is in RRC_CONNECTED state, if onDemandSIB-Request is configured, the transmission of the DedicatedSIBRequest message is initiated according to 5.2.2.3.5 and 5.2.2.3.

6.

47. The method according to any one of claims 40 to 45, wherein If the transfer mode is set to: - Broadcast, then obtain the system information message according to the content defined in clause 5.2.2.3.2 of TS 38.331, - non-broadcast, and the device is in RRC_IDLE or RRC_INACTIVE state, initiates transmission of the RRCSystemInfoRequest message according to 5.2.2.3.3 and 5.2.2.3.4, and - Non-broadcast, and the device is in RRC_CONNECTED state, if onDemandSIB-Request is configured, the transmission of the DedicatedSIBRequest message is initiated according to 5.2.2.3.5 and 5.2.2.3.

6.

48. The method according to any one of claims 40 to 47, wherein If the transmission mode is set to non-broadcast and onDemandSIB-Request is not configured, the apparatus sends a message to request configuration of onDemandSIB-Request parameters through an RRCReconfiguration message.

49. The method according to any one of claims 40 to 48, wherein If the transmission modes of the system information messages in the legacy information element and in the advanced information element are different, the transmission mode is selected based on a policy or configuration, wherein one or more of the following preferences or conditions are checked: - whether broadcast or on-demand is preferred, - whether the transmission mode in the legacy information element or the transmission mode in the advanced information element is preferred; - Whether the UE is in RRC_IDLE / INACTIVE state or in RRC_CONNECTED state.

50. A wireless device, wherein: The wireless device includes transmitter, Receiver, Controller A storage medium comprising instructions of a program for causing the wireless device to: Determine the need for a collection of system information messages, Determining, for each system information message of the required set, a corresponding broadcast state indicating a transmission mode of the system information message from a network entity, wherein determining the transmission mode comprises: - determining whether an advanced information element is stored in or has been received by the wireless device, and - after determining that an advanced information set is stored in the wireless device or has been received by the wireless device, determining a corresponding transmission mode of the system information message in the legacy information element and / or in the advanced information element.

51. A computer program product comprising code means for producing the steps of claim 17, 19, 24, 33, 39 or 40 when run on a computer device.

Images