Contact tracking for low power asset trackers

Abstract

The present invention relates to an asset tracking system and method that allows telecommunications or other wireless networks to track a low-capability, low-cost asset tracker while significantly reducing the power demand for the asset tracker by providing interrelation tracking by the tracker over a low-power local communication protocol. Contact may be reported to a network that can optimize the power usage of trackers and position certainty of tracker position estimates stored in its ongoing model by reducing the number of uplink or D2D transmissions and / or transmit power, and / or by fixed or dynamic clustering as needed.

Description

Technical Field

[0001] The present invention relates to a tracker control system for contact tracing, asset tracking, etc. in, for example, wireless networks such as, but not limited to, cellular networks, particularly fifth generation (5G) or higher generation cellular networks. Background Art

[0002] Contact tracing, in which devices identify other devices observed within a certain range, has proliferated in recent years, driven by public health and other use cases. Ruoxi Sun et al., “An Empirical Assessment of Global COVID-19 Contact Tracing Applications,” arXiv:2006.10933v6 [cs.CR] 22 January 2021, describes that a problem with contact tracing is that a central authority may perform a linkage attack to discover a user’s location history from interactions with other users. Samuel Brack et al., “CAUDHT: Decentralized Contact Tracing Using a DHT and Blind Signatures,” IEEE 2020, discloses options for defending against such attacks. While the possibility of linkage attacks in contact tracing is considered a problem in the public health setting, it can be used to provide desired functionality in asset tracking use cases.

[0003] Asset tracking utilizes sensors and / or connected devices to enable remote monitoring and management of the geographic location (geolocation) and / or movement of assets. Some manufacturers of Bluetooth-based asset trackers have added contact tracking as an additional feature to their products (e.g., Bluetooth Low Energy (BLE) tags for indoor asset tracking, which can be worn by people or attached to key equipment, and real-time and historical contact tracking). Real-time contact tracking enables organizations to monitor the number of people present in a specific area and implement social distance measurements by establishing active density controls. However, contact tracking and tag tracking capabilities are not integrated in such products.

[0004] Additionally, asset tracking is a use case for future telecom networks. An initial use case was defined for asset trackers in 3GPP specification R17 TR 22.836, but tracking of objects smaller than the size of a pallet was not considered.

[0005] The cost reduction of chipsets and other advances have greatly reduced the cost of asset trackers for narrowband IoT (NB-IoT) and long-term evolution of machines (LTE-M) systems, which means that more assets can be tracked in the future. One example is a printable NB-IoT-based tracking label to monitor its products through the supply chain. This smart label integrates cellular subscriber identity module (iSIM) functionality (as a layout on printable silicon) into the communication module along with a printable battery, microprocessor, antenna, modem, and several sensors. After printing and attaching to the packaging, it connects to the cellular network when it is torn or cut.

[0006] Like Mario H. As demonstrated in ranging studies by Garcia et al., “A Tutorial on 5G NR V2X Communications,” IEEE Journal of Communications Surveys and Tutorials (DOI 10.1109 / COMST.2021.3057017) and Zoraze Ali et al., “3GPP NR V2X Mode 2: Overview, Models and System-Level Evaluation,” IEEE Access, June 29, 2021 (DOI: 10.1109 / ACCESS.2021.3090855), existing device-to-device (D2D) communication methods can allow some form of contact tracking (in coverage or out of coverage), but typically require too frequent communications and furthermore do not provide network-side assets with a simple way to modify the functionality of the contact tracking performed by the device over the D2D link. Therefore, requirements for asset tracking systems include long battery life or generally low power consumption of the asset tracker, thereby requiring a power saving communication mode.

[0007] Asset tracking is also a use case for IoT applications and / or systems, and the involvement of public networks (such as 5G networks) is advantageous for ubiquity. However, the long-range communication protocols used by such networks remain energy intensive compared to short-range or local protocols, and thus the number and range of such communications should be minimized to save energy for the tracker. Summary of the invention

[0008] It is an object of the present invention to provide improved asset tracking with reduced energy consumption.

[0009] This object is achieved by an apparatus as claimed in claims 1 and 7, a tracker as claimed in claim 11, a tracker control system as claimed in claim 13, a method as claimed in claims 14 and 15, and a computer program product.

[0010] According to a first aspect, there is provided an apparatus (e.g. at the tracker) for controlling a tracker to provide information about the tracker and / or a tracked item to a tracker control system via a wireless network, wherein the apparatus is adapted to:

[0011] Perform local contact tracing of other tracers; and

[0012] A contact report derived from the local contact tracking is provided to the tracker control system.

[0013] According to a second aspect, there is provided an apparatus for controlling a tracker control system operating via a wireless network (e.g. at an access device of the wireless network or at a core network function of a core network of the wireless network or at a tracker having a role of a cluster head of a tracker cluster), wherein the apparatus is adapted to:

[0014] obtaining information about a plurality of trackers and / or tracked items of the tracker control system, the information being reported by at least one tracker of the plurality of trackers via contact tracking; and

[0015] Controlling at least one of the plurality of trackers to change at least one of a contact tracking range and a sleep and / or wake-up period and / or to reduce a number of uplink transmissions and / or to form a tracker cluster. For example, such changes may be made to control a trade-off between position estimation accuracy and energy consumption of the plurality of trackers.

[0016] According to a third aspect, there is provided a tracker comprising the apparatus of the first aspect, or if the tracker is operated as a cluster head, the apparatus of the second aspect.

[0017] According to a fourth aspect, there is provided a tracker control system comprising a plurality of trackers according to the third aspect and a wireless network comprising the apparatus according to the second aspect in a network device and / or a cluster head of a cluster of cluster trackers.

[0018] According to a fifth aspect, there is provided a method of controlling a tracker to provide information about the tracker and / or a tracked item to a tracker control system via a wireless network, wherein the method comprises:

[0019] Perform local contact tracing of other tracers; and

[0020] A contact report derived from the local contact tracking is provided to the tracker control system.

[0021] According to a sixth aspect, there is provided a method of controlling a tracker control system operating via a wireless network, wherein the method comprises:

[0022] obtaining information about a plurality of trackers and / or tracked items of the tracker control system, the information being reported by at least one tracker of the plurality of trackers via contact tracking; and

[0023] Controlling at least one of the plurality of trackers to change at least one of a contact tracking range and a sleep and / or wake-up period and / or to reduce a number of uplink transmissions and / or to form a tracker cluster. For example, such changes may be made to control a trade-off between position estimation accuracy and energy consumption of the plurality of trackers.

[0024] Finally, according to a seventh aspect, a computer program product is provided, comprising code means for producing the steps of the above method according to the fifth or sixth aspect when executed on a computer device.

[0025] Thus, low-capability, low-cost (asset) trackers are allowed to be tracked by a telecommunications network or other wireless network, while significantly reducing the power requirements of the asset trackers through mutual contact tracking of the trackers over a low-power local protocol. The contact may be reported to the network to provide optimization of the power usage of the tracker for location certainty of the ongoing model by reducing the number and / or transmit power of uplink or D2D transmissions, and / or through fixed or dynamic cluster formation as required. A contact report may be a message sent by a tracker and containing information related to the tracker, the tracker type or the tracker sensed value or the tracker location. In a specific example, the contact report may include information about the contact with another tracker. This may include the contacted tracker identity and / or the contacted tracker type and / or the contacted tracker sensed value and / or the contacted tracker location and / or the contacted tracker location information.

[0026] Therefore, by reducing the number of uplink and / or D2D transmissions required and / or reducing the relative time the tracker spends in awake mode versus sleep mode, the power requirements of the tracker of the asset tracking system can be reduced under the control of the network side model while maintaining the desired level of positioning accuracy.

[0027] The location-related information may be location information (e.g., geographic coordinates or distance, etc.) or other location-related information, such as the presence of other trackers, or the signal strength (or other properties) of signals received from other trackers. The location system then uses the other location-related information to create an estimate of the tracker's location, obtain an identifier of the item (to which the tracker is attached), the type of item (to which the tracker is attached), and / or a sensed value (e.g., temperature) of the item (to which the tracker is attached).

[0028] Additionally, local contact tracking allows asset trackers to form persistent clusters that stay together even when out of network coverage. This allows trackers to search for contacts locally when out of coverage (where the tracker may be geographically mobile) and use these to enable the network to maintain knowledge of its location. The network can also use such mobile trackers to search for out of coverage clusters.

[0029] According to a first option that can be combined with any of the first to seventh aspects above, local contact tracking can be configured to save energy of trackers of a tracker control system by at least one of the following: combining individual contact reports to reduce the number and range of uplink communications required for any of the trackers, allowing network or cluster controlled sleep and / or wake-up cycles of trackers, and delegating the task of maintaining network contact to a tracker (e.g., a tracker predicted to have a longer operational lifetime than other trackers in its vicinity). Thus, contact tracking can be configured to optimize the scheduling of communication and activity periods of the trackers to reduce energy consumption of the trackers.

[0030] According to the second option which can be combined with the first option or any one of the first to seventh aspects described above, even outside the coverage of the wireless network, the functionality of the tracker can be maintained by enabling the tracker to be locally provisioned and maintained in such a way that the tracker can be discovered at an appropriate time and report information about the contact that occurred with the tracker outside the coverage. Therefore, independent and isolated trackers can be detected and reintegrated into the network or cluster to optimize communication efficiency and energy consumption.

[0031] According to a third option which can be combined with the first option or the second option or any one of the first to seventh aspects described above, the contact tracking range and / or the sleep and / or wake-up cycle of the tracker can be controlled based on at least one of the position and the detected movement of the tracker. Thus, each tracker can reduce energy consumption by adapting its operating parameters to its position and movement state.

[0032] According to the fourth option which can be combined with any one of the first to third options or any one of the first to seventh aspects above, the tracker can be controlled to enter a provisioning mode, in which the tracker attempts to discover wireless networks and / or local trackers that are part of a cluster. Thus, a newly added tracker can be integrated into the tracking location system and incorporated into an existing cluster.

[0033] According to a fifth option which can be combined with any one of the first to fourth options or any one of the first to seventh aspects above, a network-side model may be provided and configured to control the tradeoff by changing at least one of the contact tracking ranges and the sleep and / or wake-up cycles of the plurality of trackers. Thus, the wireless network may be configured to control the tradeoff between the accuracy of the position estimation and the energy consumption of the tracker control system.

[0034] According to a sixth option which can be combined with any one of the first to fifth options or any one of the first to seventh aspects described above, the network-side model can be adapted to calculate known or inferred location-related information of each of the plurality of trackers using the received identification information reported by the plurality of trackers and the known location-related information of some of the plurality of trackers and / or non-tracker devices. Thus, even if some trackers are out of coverage, location estimates of all trackers of the tracker control system can be continuously provided through contact tracking.

[0035] According to the seventh option which can be combined with any one of the first to sixth options or any one of the first to seventh aspects described above, provisioning of at least one cluster of trackers can be enabled in a manner that the cluster is discoverable by the trackers or the tracker control system and is configured to report information about contacts that occurred with the trackers of the cluster when out of coverage of the wireless network. Thus, even if some trackers of the cluster are out of coverage, position estimates of all trackers of the tracker control system can be continuously provided through contact tracking in the cluster.

[0036] According to an eighth option which can be combined with any one of the first to seventh options or any one of the first to seventh aspects, a synchronization device for providing a time synchronization reference signal to a cluster tracker within a cluster range can be provided. Therefore, nearby clusters can be detected by the tracker based on their synchronization reference signals.

[0037] It should be noted that the above-mentioned apparatus can be implemented based on a discrete hardware circuit having discrete hardware components, an arrangement of an integrated chip or chip module, 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 (e.g., the Internet).

[0038] It should be understood that the devices of claims 1 and 7, the tracker of claim 11, the tracker control system of claim 13, the methods of claims 14 and 15 and the corresponding computer program products may have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

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

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

[0041] In the following figures:

[0042] Figure 1 schematically illustrates a block diagram of a tracker control system according to various embodiments;

[0043] Figure 2 Schematically illustrates a signaling and processing diagram for a provisioning process according to an embodiment;

[0044] Figure 3 Schematically illustrates a signaling and processing diagram for a main usage phase according to an embodiment;

[0045] Figure 4 Schematically shows a flow chart of a supply process and a main use phase process according to a corresponding embodiment;

[0046] Figure 5 schematically illustrates an example of an asset tracking system with independent mode and dynamic clustering according to an embodiment; and Figure 6 Detailed description of the invention shows a positioning system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0047] Embodiments of the present invention are now described based on ranging and / or positioning (sometimes also referred to as "location") services for cellular networks, where, for example, 4G network elements may be incorporated into the proposed 5G solution, and / or 5G and / or 5G New Radio (5GNR) radio access technologies may be used. However, the present invention and its embodiments are not limited to cellular networks, and may also be used in conjunction with other wireless technologies (e.g., IEEE 802.11 / Wi-Fi or IEEE 802.15.4 / Ultra-Wideband Communication (UWB), Bluetooth, Thread) where asset tracking may be supported.

[0048] Asset tracking refers to methods of tracking physical assets by scanning barcode tags attached to the assets or by using tags to broadcast their location using, for example, Global Positioning System (GPS), BLE, Long Range (LoRa), Radio Frequency Identification (RFID), WiFi, or DECT 2020. These technologies can also be used for indoor tracking of people wearing tags.

[0049] An asset tracker (sometimes referred to as a "tracker" in this disclosure) will be understood as a device (eg, tag, sensor, etc.) that enables remote monitoring and / or management of the geographic location and / or movement of an item or asset.

[0050] You can use asset tracking, for example, to:

[0051] Tracking (the identity of) an item at a specific known location (e.g., in a container), or

[0052] Identify what type of item is in a particular location, or

[0053] Identify characteristics of the item (or environment) to which the tracker is attached (or in which the tracker is deployed) (e.g., a specific sensor output, such as the temperature of a temperature sensor), or

[0054] • Retrieve the location of trackers, and therefore the items they are attached to.

[0055] Trackers may be attached to items (or deployed in a given area) to track the items.In this disclosure, an asset tracker may be considered to be a specific class of user equipment devices (UE) that may implement a subset of the 3GPP specifications.

[0056] Throughout this disclosure, the term "wireless network" is intended to mean the entire network system (e.g., a 4G or 5G system) including a communication device (e.g., UE) radio access network (RAN) and an optional core network (CN). In addition, the abbreviations "eNB" (4G terminology) and "gNB" (5G terminology) are intended to mean access devices, such as cellular base stations or WiFi access points or UWB PAN coordinators. The eNB / gNB is part of the RAN, which can provide an interface to functions in the CN. The RAN is part of a wireless communication network. The RAN implements the radio access technology (RAT). Conceptually, the RAN is located between communication devices such as mobile phones, computers, or any remotely controlled machines, and provides a connection to their CN. The CN is the core part of the communication network, which provides many services to customers interconnected via the RAN. More specifically, the CN directs communication flows through the communication network and possibly other networks. In the 3GPP specifications 23.303, 23.304, 24.334 and 24.554 for 4G and 5G networks, respectively, the so-called Proximity Services (ProSe) functionality is defined to enable connections for cellular communication devices (e.g., UEs) that are temporarily out of the coverage of an access device (eNB), etc. This specific functionality is called ProSe UE to Network Relay or Relay UE. Relay UE is a communication device that helps another out-of-coverage (OoC) UE communicate to the eNB (i.e., access device) by relaying application and network data services 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" specifies the interface defined by ProSe for sidelink communication. In addition, the abbreviation "UL" is used for an uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used for a 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 / D2D communication between two or more communication devices (e.g., UE).

[0057] Once the relay relationship is established, the OoC-UE connects via the relay UE and plays the role of a "remote UE". This situation 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 TS22.261 v16.10.0).

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

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

[0060] Ranging can be defined as the 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 are envisioned to be supported with or without network coverage. After 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 should interact with each other if they are in line of sight (e.g., in the same room).

[0061] A so-called ranging reference signal may be used to determine the distance and / or angle between two devices that may be connected via a D2D connection (e.g., using a sidelink and / or PC5) rather than an infrastructure connection (e.g., using a Uu interface). A ranging reference signal may be a position reference signal and / or a sounding reference signal or other signal (e.g., a signal for round trip time (RTT) measurement) that may be used to determine the distance and / or angle between devices, and the determination of the distance and / or angle between devices may use resources used for device-to-device (e.g., sidelink) communication (which may be configured or permitted by the 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.

[0062] Not every device will be able to calculate angles, as it would require multiple antennas. The ranging capabilities of the device (the ranging capabilities of the device may be exchanged as part of the discovery process) may be used to determine what the device is capable of and which measurements may be made. Note that angle calculation may need to be an explicit capability, rather than simply a capability based on the declared number of antennas. The number of individual antennas being greater than 1 does not automatically imply that the device is capable of calculating angles. Calculation of angles may further require sensors (e.g., magnetometers, gyroscopes, accelerometers) to derive an orientation and / or angle toward a reference point (such as magnetic north), as well as an angle / orientation calibration mechanism. The angle may also indicate an altitude difference, and a reference altitude (e.g., meters above sea level and / or barometric pressure, floor information, terrain height data for the device location) and an altitude calibration mechanism may be used.

[0063] 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” can produce two parameters, which are the distance between the two UEs in meters and the angle (in degrees) at which the target UE is elevated relative to the observer UE in the 3D plane.

[0064] Furthermore, so-called "peer ranging" can be accomplished in many ways, including but not limited to:

[0065] i. Two-way ranging is the process of two devices A and B transmitting data packets and acknowledgment packets to each other. Time delays due to natural radio signal propagation and due to processing delays on device B (i.e., the time it takes for device B to resend a packet to device A) are taken into account in this technology. The one-way flight time is then calculated on device A, which is 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 a response packet back to A. Device B includes information in its response packet so that A can calculate the time it takes B. Then at device A, the one-way flight time can be used to calculate the distance between the two devices A and B. Device B can perform the same process as device A so that B can also calculate the distance. In this technology, the clocks of the two devices do not need to be synchronized with each other because processing delays are taken into account in two consecutive packet transmissions, and the distance can be calculated simultaneously in both devices.

[0066] ii. One-way ranging is the process of sending at least one packet between a transmitting wireless device A and a receiving wireless device B. The devices are synchronized with each other through a common clock source. The flight time is then measured as the difference between the reception time at device B and the transmission time at device A. Device A may include a timestamp of its transmission time within the data packet so that device B can calculate the time difference. The accuracy of the ranging depends on the accuracy of the clock synchronization that can be achieved between the two devices.

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

[0068] Positioning can be defined as the process of determining the position coordinates of a wireless device (such as, but not limited to, a mobile phone, a wearable device, and an IoT device) according to a position coordinate system. When the position coordinates of a device are determined, a mapping function can be used to locate it on a map. Positioning is usually distinguished between absolute positioning (i.e., determining geographic coordinates (position coordinates) according to a standardized geographic coordinate system) or relative positioning (i.e., determining coordinates (e.g., using a local coordinate system) and / or an angle plus distance relative to a reference point). Some examples of how absolute or relative positions can be expressed can be found in the 3GPP specification TS23.032. A classic example is a satellite-based location service (e.g., a global positioning system (GPS) or a global navigation satellite system (GNSS)), in which well-known processes such as triangulation and trilateral measurement are used to calculate the position coordinates of a device using at least three satellites belonging to a constellation of medium earth orbit (MEO) satellites among many satellites, where the satellite acts as a clock synchronization source, and the communication delay of the transmitted packet is used to estimate the position coordinates. These coordinates can be used by any third-party map tool (e.g., OpenStreetMap) to pinpoint the location of the device in 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 indoor floor plans using indoor coordinates estimated based on RF propagation characteristics (such as time delay, multipath reflections, received signal strength, etc.) measured using RF communication between tags and anchor nodes placed in pre-known locations in the building. In an example, signal strength can be used directly to estimate distance or multiple distances and locations can be estimated at once using multiple collected measurements to obtain better performance.

[0069] Positioning techniques for obtaining coordinates of the current location of the device can be implemented in several ways, but generally 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 may be determined using a variety of techniques, which may include round trip time (RTT), time of flight (ToF), time difference of arrival (TDoA), angle of arrival / departure (AoA / AoD), and / or combinations thereof:

[0070] The round trip time (RTT) defines the duration from the time a data packet is sent by a transmitter (Tx, e.g., access point / device) to the time a receiver (Rx, e.g., mobile phone / device) receives and acknowledges the same data packet (i.e., until the moment the acknowledgement is received by the transmitter). Since data packets travel at the speed of light (approximately 3.3ns / m) in the air medium, the duration that the data packet travels in the air is proportional to the actual distance between Tx and Rx. In scenarios 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 timestamp and the received timestamp, as it will also include timing errors caused by internal clock drift and uncertain clock offsets between Tx and Rx, etc. Since the internal clocks of Tx and Rx are not synchronized, the difference in timestamps when the signal travels in the reverse direction (i.e., Rx to Tx) is affected by the clock offset in the opposite way to that in the forward direction (i.e., Tx to Rx).

[0071] According to the round trip time concept, a data packet 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.

[0072] The round trip time (RTT) can be obtained by simple addition and subtraction of the four timestamps t1 to t4 without knowing any clock offset, as shown below:

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

[0074] Among them, t1 is the sending time, t2 is the receiving time, t3 is the confirmation sending time, and t4 is the confirmation receiving time.

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

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

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

[0078] The Time of Flight (ToF) corresponds to the duration from the time a data packet is sent by a transmitter (Tx, e.g. an access point / device) to the time the same data packet is received by a receiver (Rx, e.g. a mobile phone / device). Note that this approach 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 offsets between Tx and Rx can be compensated. Assumptions Figure 3 The Tx and Rx are synchronized, and the distance D between Tx and Rx can be calculated by the following equation:

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

[0080] 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 by its own measured timestamp t2. The time of flight can also be calculated by Tx knowing the timestamp t2 (which is for example transmitted later 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 estimating multiple distances, which can then be converted into estimates of position coordinates (local and global) when the coordinates of multiple reference devices (acting as transmitters or receivers) are known in advance.

[0081] The arrival time difference corresponds to the difference in the timestamps of the data packets received by multiple clock-synchronized receivers (Rx, e.g., access points / devices acting as synchronous location reference stations), whereby the data packets are 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 the other way around, e.g., the mobile phone / device can be an asynchronous Rx, and the access point / device can be a synchronous transmitter. Note that a single transmission of a data packet by a transmitter will be received concurrently by several synchronous receivers placed within the coverage area of ​​the transmitter. It is important 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 receivers. The central location server can receive the arrival time of the data packets from each receiver i=0...N, and can calculate the distance difference for any pair of receivers (i, j) for a particular transmitter based on the following equation:

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

[0083] where c is the speed of light, and Δt ij is the arrival time difference between receiver i and receiver j, d i is the unknown Tx to Rx distance for receiver i, Δ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 to estimate the distance difference, which can be converted to position coordinates (local and global) when the coordinates of the receiver are known in advance. Note that the transmitter cannot calculate its own position locally on the device, and only the location server can calculate the location of the transmitter using the positioning infrastructure and the network of synchronized receiver nodes. Note that the location server can be located on one of the clock-synchronized receivers. The location of the transmitter can be transmitted via a separate communication channel (e.g., to the application, to the transmitter, or to one or more receivers), or can be modified in one of the responses from the receiver to the transmitter in the same channel used to send the data packet.

[0084] Alternatively or additionally, the receiver may send its measurements (e.g., arrival time information) rather than 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) as defined in 3GPP TS25.305 and TS36.133 and Uplink Time Difference of Arrival (UTDOA) as defined in 3GPP TS25.305, which is typically based on a Positioning Reference Signal (PRS) or a Sounding Reference Signal (SRS).

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

[0086] Furthermore, the angle of arrival concept is based on phase difference considerations. The angle of arrival of an incoming RF signal can be calculated as follows. In principle, at least two RF signals separated by a distance d with different receive phases are The antenna receiver can determine the phase difference of the received signal at the receiver Then use the phase difference The angle of arrival is estimated based on the following equation:

[0087]

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

[0089] The angle of arrival of the RF signal at the receiver can be estimated based on the measured phase difference using a naive approach using the following equation:

[0090]

[0091] Note that in addition to the above methods, there are several well-known methods that can be used to calculate the angle of arrival of RF signals, including but not limited to Bartlett beamforming (see MSBartlett: "Smoothing Periodogram 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", Proceedings of 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 sent 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.

[0092] 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, such as described in the "Functional stage 2 description of Location Services (LCS)" for 4G in 3GPP specification TS23.271Rel-16 and the "5G System (5GS) Location Services (LGS); Stage 2" for 5G in 3GPP specification TS23.273Rel-17.

[0093] 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-5km) and provide good accuracy in outdoor environments, where line of sight (LOS) of a base station is possible and communication paths can be fairly modeled and considered 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., 20m) and provide good accuracy in outdoor and especially indoor environments, where two ranging devices can also be in line of sight (LOS) with each other.

[0094] The functionality of the location service and the ranging service may be combined to provide, for example, a location service with improved accuracy and better indoor position estimation.

[0095] Note that location services may also provide ranging services, for example, where the positions of two devices may be observed / determined, for example, via GNSS, the distance and / or angle between the two devices may be calculated and may be 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 requested 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.

[0096] The conversion of distance to coordinates can be implemented, for example, based on ranging measurements, by which the first device A can obtain the distance (d) and angle (tc) to the 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.

[0097] 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 the spherical-earth approximation model, the following equation can be used to calculate the geographic coordinates of device B (lat2, lon2):

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

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

[0100] Ion2=[mod(Ion1-dlon+π,2*π)]-π

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

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

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

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

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

[0106] Alternatively, the conversion of distances to coordinates of a coordinate system may be accomplished using other concepts such as the inverse Havershine formula, length in degrees, Molodensky method, and block shift method, depending on the accuracy required and the type of coordinate system used by the application.

[0107] Current techniques for ranging and location estimation can be improved in the following areas:

[0108] i. Position accuracy is highly dependent on signal path loss and degrades with loss of signal quality in indoor and deep indoor environments where cellular coverage is very poor. In addition, in remote outdoor environments, where the number of base stations is limited and results in sparse to no signal coverage, the accuracy of location services becomes poor. In such areas, depending on the positioning method used, triangulation or triangulation of a mobile device (e.g., UE) may require a longer initial latch time to be able to simultaneously receive at least three different signals from at least three different base stations. If a mobile device moves 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 unavailable for real-time location tracking.

[0109] ii. The ranging accuracy in outdoor environments depends largely on the channel variability and reflective properties of objects around 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 the objects and surroundings before ranging between two devices, while in outdoor environments, the control of the environment is uncertain and often has a negative impact on the ranging accuracy. In addition, due to possible Doppler effects in the RF propagation channel, the movement of the mobile device in the outdoor environment may also have a great impact on the ranging accuracy. Therefore, ranging measurements between two devices in an outdoor environment may become unusable due to the effects of severe degradation in the RF channel.

[0110] Some use cases may require conversion of ranging measurements into location coordinates, which enables UEs that cannot 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 in indoor environments, may benefit from ranging, so that the positioning accuracy is increased from hundreds of meters to sub-meter accuracy in indoor and / or out-of-coverage environments. In addition, accurate positioning and continuous tracking of low-power IoT devices is a requirement for yet another use case that may enable adaptive delivery of Quality of Service (QoS), for example, providing high bandwidth at location X and only low bandwidth in location Y, depending on the location. Some of the identified suitable use cases may require the formation of UE clusters based on location information to deliver location-based QoS to groups of UEs.

[0111] 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 a skilled person, may be used.

[0112] In the following, embodiments are described in which a cluster of similar trackers is used to reduce power consumption.

[0113] Li Manman et al.: “Energy-Efficient Dynamic Clustering for IoT Applications: A Neural Network Approach,” IEEE 8th International Conference on Communications and Networking (ComNet), October 27-30, 2020 (DOI: 10.1109 / ComNet47917.2020.9306092) describes the use of dynamic cluster formation for energy-efficient data transmission in Internet of Things (IoT) networks. Neural networks and associative structure theory are used to process the amount of information based on the power requirements of individual clusters. This avoids information redundancy and resource waste caused by repeatedly constructing similar types of clusters (as in conventional methods). Based on the power requirements, the nodes are divided into two initial clusters based on the application and compared with a set threshold. It is then used to assign logical values ​​to the nodes in the cluster, thereby efficiently utilizing the information in the cluster and effectively balancing the inter-cluster collaborative communication energy for IoT applications.

[0114] According to Nathalie Barbosa Roa et al.: “A novel algorithm for dynamic clustering: properties and performance”, 15th IEEE International Conference on Machine Learning and Applications (ICMLA), December 2016, Anaheim, USA, pp. 565-570 (10.1109 / ICMLA.2016.0099.hala-02004417), the likelihood of a given node joining a given cluster depends on the interaction range (among other parameters).

[0115] Similar behaviors were also studied by Damian Roca et al.: “Emergent Behaviors in Internet of Things: The Ultimate Ultra-Large-Scale System”, IEEE MICRO, SPECIAL ISSUE IOT, in the context of “queuing” of smart devices (e.g., self-driving cars).

[0116] More broadly, many types of soft information (such as specific network access, etc.) have been proposed for localization in the Internet of Things (LoT).

[0117] According to various embodiments, low-power asset trackers that enable a tracker control system (or tracking system) to reduce the number and / or energy costs of their network transmissions while still enabling a central server in a telecommunications network to calculate their locations, for example by “contact tracking” other nearby asset trackers with each other in a protocol that allows the range and other parameters of the contact tracking to be determined at least in part by a network-side entity based only on intermittent communications with a subset of the trackers.

[0118] Note that the purpose of communicating with the asset tracker may not only be calculation / estimation of the tracker position, but may also be at least one of retrieval of identity, retrieval of asset type, and retrieval of sensed values.

[0119] It should also be noted that the optimization goal can not only be reduced energy or less network transmission. It can also be lower latency (because there is no multi-hop communication) and / or higher reliability (because all or more trackers are reachable).

[0120] By controlling the distance range at which asset trackers register additional contacts (via controlling transmit power), a network-side server or application can maintain and manipulate a statistical model that gives the location and other details of each tracker (such as usage status).

[0121] In the following, various embodiments are described. Figure 1 Further details of its hardware components are described later in Figures 2 to 5 Describes further details of its procedural and signaling steps.

[0122] At initial switch-on, or as needed during use, the asset tracker may enter a provisioning mode in which the asset tracker attempts to discover the network (e.g., by listening to synchronization signals and master information blocks (MIBs), system information blocks (SIBs), or beacons from nearby access devices) and / or local trackers, which may be part of a cluster and may broadcast synchronization signals (which may be, for example, a synchronization reference UE (SyncRef UE) as defined in 3GPP specification TS 38.133, or an alternative implementation providing similar functionality). For simplicity, the following description uses the term "SyncRef UE", while it may also mean an alternative implementation providing similar functionality or related functionality, such as a UE providing discovery or synchronization signals via sidelink / D2D communications or a UE providing SIB / MIBs to a network relay device via ProSe relay communications.

[0123] When the asset tracker has found a suitable network or SyncRef UE and / or has set up provisioning by receiving a suitable basic communication schedule, the network (or cluster head) may provide the asset tracker with data specific to the present system, which may include expected sleep / wake cycles, tracking range, and / or other setup details (e.g., the portion of the wake-up cycle to send uplink communications to the network).

[0124] The asset tracker, either individually or as part of a cluster, sends an identity (ID) via the local area protocol using the received transmission details. It may also listen to the received ID. The ID may have been configured during setup as described above or during manufacturing and is expected to be unique in the context of the local area protocol.

[0125] The asset tracker may also send other information, such as information about at least one of the type of asset to which it is attached, characteristics of the asset including real-time characteristics of the asset (such as sensed values), and location-related information about the asset.

[0126] When the asset tracker is in the coverage area (coverage range) of the network, it (or the cluster head if the asset tracker is in an existing cluster) may report to the network itself and its received ID and (if available) location, parameters indicating signal strength (such as received signal strength indicator (RSSI) or reference signal received power (RSRP)) or parameters indicating positioning, distance, angle or positioning, distance or angle measurement (e.g., coordinates in a coordinate reference system, distance in meters, angle in degrees relative to a reference direction / line, or TDOA timing) and / or possible other details (such as battery life) after a scheduled delay time (which may be configured or preset by the network). This type of information will be understood as an example of "location information" or "location-related information".

[0127] A network-side model maintained at the network or application uses the received IDs and / or the known positions of some asset trackers (e.g., syncRef UEs or anchor nodes) or gNBs to compute the known or inferred positions of all asset trackers (including any unseen asset trackers) at each time step. In some cases, such as where the computed position of an unseen asset tracker appears close to the most recently reported position, or when the number of received IDs is less than the number of expected IDs, the network may optionally contact each of the relevant asset trackers and instruct them to modify their tracking range, modify their sleep / wake-up behavior, reduce the number of uplink transmissions, and / or form a cluster. By doing so, the network-side model or application may, for example, optimize between position certainty and / or energy usage (e.g., by reducing the frequency and range of uplink transmissions) and / or reliability of the asset trackers.

[0128] The network can maintain a continuous estimate of the location of the asset tracker, cluster, and status data (e.g., battery life and / or energy generation status of integrated energy harvesting elements) that is provided (exposed) to appropriate applications. This can be done continuously or based on a (one-time) request.

[0129] When an asset tracker is not in the coverage area of ​​a network (out of coverage) and is already part of a cluster, it can continue to operate in cluster mode. It should be noted that some asset trackers in a cluster may be in coverage while other asset trackers in the same cluster are out of coverage. The goal is to maintain knowledge of the members of the cluster and remain discoverable to any network if the asset tracker moves into coverage after at least a certain delay period.

[0130] One asset tracker of a cluster may act as the source of synchronization signal for the cluster (ie, it acts as a SyncRef UE). This task may be dynamically shared among the trackers of the cluster based on battery or hardware considerations.

[0131] When an asset tracker is not in the coverage area of ​​the network (out of coverage) and is not part of a cluster, it becomes an isolated asset tracker. In this case, it can broadcast, for example, its (protected) ID and / or pseudo-ID and / or other relevant information such as tracker characteristics using the last available settings, and listen to any nearby network or cluster head (with the purpose of joining the network cell or cluster). The broadcast can be triggered when a trigger signal (e.g., a discovery or synchronization message) is received from a nearby tracker (e.g., a UE) or access device. Protected can mean encrypted (e.g., with the help of an NR encryption algorithm such as NEA1) and / or integrity protected (e.g., with the help of an NR integrity algorithm such as NIA1). In the rest of the specification, the asset is referred to as broadcasting its ID without loss of generality. By varying the relative time spent with an active receiver (Rx on) and / or transmit power, the possibility of discovering an isolated asset tracker can be weighed against battery usage. Alternatively or additionally, the asset tracker may use Model A or Model B ProSe discovery to send Model A announce messages or Model B solicit messages, and / or listen to incoming Model A announce messages or Model B response messages to solicit messages on the sidelink to / from UEs or other asset trackers (which may or may not be part of a cluster). Such discovery messages may include a service identifier (e.g., a ProSe identifier indicating an asset tracking service) and / or a device identifier (e.g., a pseudo-ID of the asset tracker or other UE / asset tracker) and / or an attribute / flag indicating a capability / request for asset tracking and / or an identifier (e.g., a ProSe identifier indicating a cluster formation service) or an attribute / flag indicating a capability / request to form a cluster. After discovery by another UE / asset tracker, the asset tracker may be added to the cluster, or a new cluster may be formed. The asset tracker or another UE / asset tracker may send one or more messages to request / confirm the addition / formation of a cluster (e.g., via a direct communication request message), whereby the message may include information about the cluster (e.g., a cluster ID). Additionally or alternatively, asset tracking may be performed, for example, by reporting the sighting and / or location of the asset tracker or another UE / asset tracker to the network or to another asset tracker (e.g., based on information obtained from a discovery message, which may include a signal strength determination for estimating distance, and / or based on a set of subsequent messages between the asset tracker and the other UE / asset tracker and / or the network or another asset tracker).

[0132] Additionally, communication frequencies and other settings can be changed automatically by the asset tracker or cluster based on contextual cues (e.g., they can wake up when movement is detected, or enter storage mode if the same cluster members are repeatedly observed).

[0133] When the network is available, the ID and location are reported and used to update the global tracker location model as described above.

[0134] When individual asset trackers and / or cluster heads are out of network coverage, the individual asset trackers and / or cluster heads may keep the received IDs in memory and report the received IDs later when they are able to report the received IDs (e.g., when they gain network coverage again).

[0135] Alternatively, the network may actively search for out-of-coverage clusters by using any available nearby asset trackers to attempt to contact the cluster-head (eg, by temporarily increasing its tracking range).

[0136] Therefore, according to various embodiments, an asset tracker control system (asset tracking system) is provided in which the asset tracker can save energy while allowing the network side model or application to retain its location information by using a local 'contact trace' protocol with low transmission power, supplemented by less frequent contact with the network.

[0137] The contact tracking protocol may be adapted to save energy at the asset tracker in at least one of the following three ways:

[0138] i. It is configured to reduce, on average, the number and / or range of uplink communications required for any given asset tracker;

[0139] ii. It is configured to allow network or cluster controlled sleep periods (which can be set to be longer than wake-up periods), where the trade-off between the length of the sleep period and position accuracy can be controlled by the network or cluster head;

[0140] iii. It is configured (eg in cluster mode) to allow asset trackers in a cluster to maintain contact with the network by delegating the task of maintaining contact to the asset tracker with the longest remaining battery life.

[0141] In an embodiment, the contact tracking protocol may also be configured to allow the network side model (and / or local asset trackers, such as cluster heads) to optimize between location finding, battery life, and other considerations by changing the tracking range and sleep / wake cycles of the asset tracker. Optionally, these parameters may be independently changed / adjusted by the asset tracker based on data such as location, detected movement, etc.

[0142] In further embodiments, the asset tracking system may be configured to retain at least some functionality even outside of network coverage by enabling clusters of asset trackers to be provisioned and maintained in such a way that the clusters can be discovered by the tracking system at appropriate times, and report information about contacts that occur with asset trackers outside of coverage that would otherwise be unavailable to the network.

[0143] Figure 1 Schematically illustrated is a block diagram of an asset tracking system (asset tracker control system) according to various embodiments.

[0144] Each of the multiple trackers (TR) 102 of the asset tracker group (AT) 10 of the tracking system includes asset tracking hardware capable of communicating over a telecommunications network (e.g., a 3GPP 5G network or other wireless network), which in use can be fixed to a physical object for which a location (and possibly other information, such as usage status) should be tracked. More specifically, each tracker 102 may also include the required networking hardware and software in addition to other hardware such as batteries, antennas, central processing units (CPUs), and optional additional hardware such as inertial sensors, additional location and environmental sensors, etc. The tracker may use energy harvesting to gather enough energy for communication, which may result in significant delays between messages and significant delays in message responses. The tracker may also support backscatter-based communications. In backscatter communications (e.g., uplink or sidelink communication messages), information may be modulated on an incoming impact signal (e.g., an irradiation RF signal) (e.g., from a base station or other UE), thereby reflecting / transmitting the modulated signal so that a nearby base station or other UE can receive the modulated signal.

[0145] In addition, each tracker 102 can be configured to support various operating modes, including "sleep" periods (during which the radio frequency (RF) and other networking processes of the tracker 102 are substantially shut down, or are in an idle mode or in a power saving mode in which at least the local clock remains operational) and "wake-up" periods (during which at least some tracker hardware is active to allow desired functionality).

[0146] The tracker 102 may be configured to communicate using both the standard uplink and / or downlink protocols and the device-to-device (D2D) protocols as originally explained. The transmit power used for D2D communications may be variable and may be used to modify the range ("tracking range") at which an expected nearby asset tracker is able to receive D2D signals from the tracker 102.

[0147] Optionally, tracker 102 may be capable of more advanced ranging techniques, such as two-way ranging and other techniques initially explained.

[0148] Optionally, hardware with additional capabilities, such as an Installer's UE (I-UE) 40 or other mobile device, may be used by the installer during the provisioning process, as described later. Examples of suitable hardware for the Installer's UE may include a smartphone or laptop with network access.

[0149] Furthermore, the asset tracking system may include a network (NW) 20 and a network side model (NSM) 202 .

[0150] The network 20 may be a telecommunications network such as a 5G network, and the asset tracker 10 may be within range of the network 20 (“in coverage”) or outside of range (“out of coverage”).

[0151] The network 20 may provide services to (mobile) devices (e.g., 5G UE) by using base stations (e.g., 5G NR gNB or LTE eNB).

[0152] In addition to the normal RF components, the network 20 may include suitable computing hardware and software to run statistical models (eg, network-side models 202 ) based on, for example, the locations or approximate locations of the trackers 102 of the asset tracker fleet 10 .

[0153] The network side model 202 can be hosted in a network function of the network 20, such as a network function of a 3GPP 5G core network (e.g., location services such as a location management function (LMF)) or an application function (integrated via a service-based architecture (SBA) interface) or an external application connected to the core network via a network open function (NEF).

[0154] Data obtained from and / or related to and / or required by the network 20 and network-side models may be stored in a tracker location database (TP-DB) 204, which may provide (surface) the data to appropriate authorized applications (e.g., installed and / or used by the owner of the tracker 102) and / or other downstream location data clients (LD-CL) 30 as needed.

[0155] Additionally, the asset tracking system may include a cluster (CL) 106, which may be a group of at least two cluster trackers (CL-TR) 1066 physically co-located within a certain distance ("cluster range"). The cluster range may be dynamically changed by the network 20 or the cluster 106. At least one of the cluster trackers 1066 may be configured as a cluster head (CLH) 1062, which assumes the additional responsibility of maintaining information about the members of the cluster 106 (membership information) and reporting it to the network 20 when requested or when scheduled.

[0156] The cluster range may be related to the transmit power used by cluster trackers 1066 in a cluster 106 for communications and may be modified by changing corresponding parameters.

[0157] Optionally, ranging techniques more advanced than simple signal strength measurements (including any suitable trilateration or positioning techniques, as initially described) may be used to define and control cluster ranges.

[0158] Cluster 106 may exist entirely within the coverage of network 20 (i.e., all cluster trackers 1066 of cluster 106 are within the coverage area of ​​network 20 (e.g., a network cell)), partially within the coverage of network 20 (where some cluster trackers 1066 of cluster 106 are within the coverage area while other cluster trackers are outside the coverage area), or entirely outside the coverage area of ​​network 20.

[0159] When out of coverage, one member of the cluster 106 (which may or may not be the cluster head 1062) may be configured to take over the additional role of a synchronization reference UE (SR-UE) 1064 (“SyncRef UE”), which broadcasts a synchronization reference signal to be used by other cluster trackers 1066 during their wake-up periods.

[0160] In an embodiment, the role of the SyncRef UE 1064 may correspond to the role defined in 3GPP specification TS 38.133 (and elsewhere).

[0161] In another embodiment, the synchronization reference role may be an alternate role, for example, providing a lower powered implementation of a time synchronization reference signal to other cluster trackers 1066 .

[0162] The SyncRef UE 1064 may be selected as a cluster tracker 1066 that has higher precision timing available to it even outside of the coverage of the network 20 (eg, by making available a Global Navigation Satellite System (GNSS) chip).

[0163] When the cluster 106 is in partial network coverage, preferably, the role of SyncRef UE 1064 and cluster head 1062 is assumed by one of the cluster trackers 1066 in network coverage. This allows the SyncRef UE 1064 to keep the entire cluster 106 synchronized with the network 20 and synchronized locally, and allows all cluster trackers 1066 in the cluster 106 to maintain contact with the network 20 through the cluster head 1062.

[0164] In the case where multiple cluster trackers 1066 in the same cluster 106 are within coverage, they can select the appropriate SyncRef UE 1064 and cluster head 1062 from the in-coverage cluster trackers 1066 as described later in the cluster mode portion of the main usage phase procedure.

[0165] A tracker that is not part of the cluster 106 but is fully functional when the tracker is outside the coverage of the network 20 is referred to as an “isolated tracker” (ITR) 104 .

[0166] In the following, based on Figures 2 to 4 A process for locating a tracker is described.

[0167] The process is designed to save energy at tracker 102, cluster tracker 1066, and / or isolated tracker 104, for example, by reducing the number and frequency of their uplink transmissions (and the reception time of downlink information), and thus increase the life of battery-powered trackers or enable battery-free trackers. The process is also designed to retain at least some functionality when the tracker is out of coverage of network 20.

[0168] In various embodiments, the process for positioning may include two phases with related sub-processes, namely an initial provisioning phase and a main use (tracking) phase.

[0169] It should be noted that the two sub-processes may proceed differently depending on whether the tracker in question is within coverage of the network 20, partially within coverage, or out of coverage.

[0170] Figure 2 A signaling and processing diagram of an initial provisioning procedure according to an embodiment is schematically shown.

[0171] In step S201, the initial provisioning phase (I-PP) is started.

[0172] After initial switch-on in step S201 or as required during use, the trackers 102 of the asset tracker group 10 may be configured to enter a provisioning mode (PM) in which they attempt to establish contact with the network 20 or nearby cluster 106 in order to register with a location service.

[0173] In addition to the initial switch-on, tracker 102 may be configured to automatically re-enter provisioning mode as needed during periods of major usage (eg, after re-entering network coverage after a period out of coverage).

[0174] Tracker 102 may also be manually reset to provisioning mode by external operation (eg, using the installer's UE 40). This may require registering a change in ownership or status of tracker 102, for example.

[0175] Registration of the tracker 102 to the network 20 may be based on network credentials or application specific credentials, which may involve at least a tracker identity and / or secret key material.

[0176] Provisioning in provisioning mode may involve configuration of the tracker 102 for the purpose of tracking a specific application upon successful registration. This provisioning step may involve (re)configuration of a (unique) tracker ID and / or key material associated with the application.

[0177] Optionally, in various embodiments, the tracker 102 may be configured to elect to use cluster provisioning mode (CL-PM) in certain scenarios even when the tracker 102 is within coverage of the network 20. As an example, cluster provisioning may be relevant where a large number of trackers 102 are to be provisioned at once and / or where a high expected mobility (and therefore a high chance of coverage loss) is expected for the tracker 102, e.g., in the scenario of cargo pallets on a truck, where each box contains a tracker 102. In such a case, the installer's UE 40 may decide to configure the tracker 102 to use cluster provisioning mode even when network contact is available.

[0178] In step S203, the tracker checks whether it is within the coverage of the network 20. If it is determined that network contact is possible, the tracker 102 contacts the network 20 in step S205, for example, via an existing long-range protocol under 5G or any other wireless communication standard. Standard uplink downlink communications as well as dedicated protocols (e.g., NB-IoT) can be used. In general, a long-range protocol may refer to a protocol that allows the tracker to communicate directly with an access device (e.g., an access point or base station) connected to the core network.

[0179] Furthermore, in step S205, the tracker transmits its data to the network 20, which data includes the identity (ID) of the tracker (e.g. a unique ID number or an identity (ID) derived from a unique device identity (such as a Subscription Permanent Identifier (SUPI) or an International Mobile Subscriber Identity (IMSI)) (e.g. a Subscription Hidden Identifier (SUCI), see TS 33.501)) and any available installation or usage data (such as location, owner, the physical asset to which it is attached, dedicated hardware resources, remaining battery life, etc., i.e. "metadata").

[0180] In various embodiments, the ID may be permanently associated with the tracker 102 at the time of manufacture (e.g., stored in hardware on the tracker 102 or in an (embedded) smart card that may be connected to the hardware). This option may provide reduced complexity, for example by using the International Mobile Equipment Identity (IMEI) number of the tracker, but may involve security and / or privacy issues since the ID cannot be changed after any data breach.

[0181] In other embodiments, IDs may be generated by the tracker 102 or by the network 20 sequentially or according to any other suitable pattern during the provisioning process (e.g., during policy and authorization provisioning by a policy control function (PCF)). Any algorithm that generates IDs must ensure that they are unique across all trackers that may become members of an asset tracker group 10 or cluster 106. In the text that follows, the term "unique ID" is used to denote an ID that is at least unique within an asset tracker group 10 or cluster 106.

[0182] In an example, the unique ID may be a user information ID exchanged in a direct communication request (DCR) message over PC5 / sidelink.

[0183] An advantage of dynamically generating a unique ID is that if a data breach occurs, the tracker 102 can have its unique ID reset without any hardware changes.

[0184] In an embodiment, tracker 102 may set a logical flag during any subsequent return to provisioning mode, which may occur after a loss of network coverage, to inform network 20 that it does not require a new random ID as a unique ID (to avoid accidental loss of information).

[0185] In an embodiment, the unique ID may be generated by each tracker 102 by deriving it from a unique device identifier (e.g., SUPI / IMSI / IMEI), for example in a manner similar to deriving a subscription concealed identifier (SUCI), whereby the core network (e.g., in the case of SUCI, the authentication server function (AUSF) or unified data management (UDM)) may be able to un-hide the identity of the tracker from which the unique ID was derived (e.g., SUPI). In an embodiment, the unique ID may be generated or protected by each tracker 102 by a pseudo-random generation function (whereby the function / algorithm / configuration option may be pre-defined or pre-configured or downloaded on the tracker 102, for example by / from the network or by / from the installer UE), whereby the pseudo-random generation function may take a time reference (e.g., Coordinated Universal Time (UTC)) as an input, and / or whereby the pseudo-random generation function or an identifier identifying a specific pseudo-random generation function and which inputs the function uses is shared with the network and / or cluster head and / or other trackers, such that if the same inputs are applied, they may arrive at the same ID).

[0186] Optionally, the unique ID may be prepended or appended or multiplexed with the identity of the cluster / asset tracker group.

[0187] In further embodiments, the unique ID may be assigned to the tracker 102 prior to being provisioned by an installer (eg, using the installer's UE 40) using the sequence described above or other algorithms.

[0188] Optionally, the unique ID may be more difficult to protect from privacy attacks, tracking attacks, etc. The way to protect the unique ID may be by encryption (e.g., using a public key scheme) so that the unique ID sent by the tracker 102 can only be decoded by the network-side model 202 (which holds the appropriate private key), but not by any intermediate trackers that receive it.

[0189] In a subsequent step S206, the network 20 transmits data including synchronization, timing, and timing / frequency resources (e.g., sleep and wake (S / W) times) to the tracker 102 for communication with other trackers known or expected to be nearby. The network 20 may also transmit other parameters, such as a group identifier and / or security key material, to enable secure communication in the group.

[0190] Alternatively, if a suitable default data set is already stored in the tracker 102 , step S206 may be skipped.

[0191] In one embodiment, the sleep / wake timing and frequency resources may be common within a given cell (or larger area) of the network 20 for initial provisioning (e.g., based on some default values). However, they may be modified later during use, as described below in conjunction with the main use phase.

[0192] The remaining synchronization and resource allocation required for communication when in coverage can be substantially handled by the network 20 using existing protocols (e.g., standard communications or NB-IoT).

[0193] Optionally, in step S207, the network 20 may instruct the tracker to join the cluster 106 by using the cluster provisioning mode. As an example, this may be the case if the tracker 102 is already a member of the cluster 106 prior to the initial network contact. In this case, one tracker of the asset tracker group 10 (which may preferably be the cluster head 1062) may report the unique ID details of all trackers 1066 of the entire cluster 106.

[0194] Optionally, cluster IDs may be dynamically assigned to clusters 106 by the network 20 or the installer's UE 40 to aid in tracking. Similar to the individual unique IDs of the trackers 102, the cluster IDs may have encryption or security features attached to them. For example, a so-called cluster key may be assigned to attach a message integrity code (MIC) to the exchanged unique IDs, which allows the cluster head 1062 to verify that they are valid. The cluster key may be a group key, or a pairwise key between each pair of cluster trackers 1066.

[0195] After receiving the required sleep / wake cycles and other data, the tracker 102 begins (periodically) broadcasting its unique ID as instructed in step S213, and the process proceeds to the main use phase (M).

[0196] Otherwise, in case it is determined in step S203 that network contact is not available, the process branches to step S204 where it is checked whether the tracker 102 is a member of the cluster 106 (cluster mode) or a nearby cluster is discoverable.

[0197] In the event that the tracker 102 was not previously part of a cluster 106 (e.g., initial provisioning of an isolated tracker), it becomes an isolated tracker 104 and attempts to discover any nearby clusters 106 or networks 20 by setting its receiver to be active on a relevant (e.g., default and / or preconfigured) frequency band and remain active for a given length of time and search for synchronization signals from any SyncRef UE 1064 or network 20. The length of time to remain active may be selected from a predetermined set or automatically configured by the isolated tracker 104.

[0198] The longer the isolated tracker 104 remains active, the more likely it is to discover a cluster 106, at the expense of (energy) resource usage. In an example, to facilitate discovery of isolated trackers 104, a default minimum time may be specified during which a tracker acting as a SyncRef UE 1064 for any cluster 106 must be in wake-up mode (even if the remaining trackers 1066 in the cluster 106 are not scheduled to wake-up mode). For example, if the time is once an hour, any isolated tracker 104 will only need to remain active for one hour.

[0199] In case the isolated tracker 104 detects the SyncRef UE 1064, it may use the information received from the SyncRef UE in the synchronization signal (SYNC) in step S208 to contact the cluster head 1062 to join the cluster 106 in step S209 and provide its unique ID and metadata.

[0200] In step S210 , the cluster head 1062 provides a sleep / wake (S / W) cycle to the (previously isolated) tracker for future communications with the cluster 106 .

[0201] Otherwise, in case the isolated tracker did not find the SyncRef UE 1064 in step S204 during its active period, it may retry provisioning immediately at defined intervals or in case of certain detected events (e.g., motion or temperature change above a threshold), which would indicate that it may have moved.

[0202] As another option, the isolated tracker 104 may also attempt to actively contact any nearby SyncRef UE 1064. For example, this may be achieved by broadcasting its own SyncRef UE signal at high power. In the event that any nearby SyncRef UE 1064 receives such a signal, it may temporarily increase its own transmit power to allow the isolated tracker 104 to join the cluster 106, as described above in conjunction with steps S208 to S210.

[0203] The power level and repetition timing of such active broadcasts by the isolated tracker 104 may be balanced with its remaining battery life and its estimate of the likelihood of being discovered by nearby trackers (e.g., because the isolated tracker 104 was part of the cluster 106 during the last wake-up period, indicating that it may have just fallen out of range).

[0204] In various embodiments, to facilitate cluster discovery by the isolated tracker 104 in step S204, a default set of frequency resources may be reserved for use by SyncRef UEs 1064 in an out-of-coverage state, similar to the reserved resources for semi-persistent scheduling of Mode 3 or Mode 4 V2X (e.g., in 3GPP specification TS 36.331 and elsewhere).

[0205] In case the isolated tracker 104 was previously part of the cluster 106 (within a recent time period that can be configured), the isolated tracker 104 may preferably try to specifically rediscover its previous cluster 106 in step S204 before trying to discover other clusters using the above options. This scenario may occur, for example, because the isolated tracker 104 has left the cluster 106, or because the isolated tracker 104 acting as a SyncRef UE 1064 has left the cluster 106 and thus the cluster 106 as a whole has lost synchronization during its wake-up period, although most of the cluster trackers 1066 are still in the same location.

[0206] In an embodiment, the isolated tracker 104 may follow a sequential process to attempt to reestablish contact with the cluster 106 in step S204, where the last used SyncRef UE 1064 attempts to reestablish signaling within a given time period, followed by other UEs according to an ordered list.

[0207] In this way, any given cluster tracker 1066 in the cluster 106 should be able to calculate how long (up to which maximum time) a synchronization reference signal should be receivable (visible) after a failed attempt to communicate during the wake-up period. If no synchronization reference signal is received during the entire period up to this maximum time, the cluster tracker 1066 knows that it should try to become the SyncRef UE 1064 itself.

[0208] In one embodiment, a random delay may be added to the duration of each reconnection attempt to avoid any potential conflicts between two trackers with the same priority in the list. In this case, the delay may be limited to a maximum amount so that the trackers can still apply the maximum waiting period calculation as described above.

[0209] After waiting a maximum time that is expected based on the number of devices in the cluster 106 and its own position in the sequence, the cluster tracker 1066 may determine that it is the isolated tracker 104 and revert to the relevant process steps.

[0210] In the event that network contact is not possible and the isolated tracker 104 was not previously part of a cluster, the process branches to step S211, where the nearby installer's UE 40 is activated for manual provisioning (MP) and acts as a SyncRefUE and cluster head to register the unique ID of the isolated tracker 104 and provide it with sleep / wake information and communication details or information about the cluster (e.g., cluster identity, cluster credentials) in step S212. For example, a group of trackers 102 may be manually provisioned for the first time, and an operator may use a smartphone to enable them to form a cluster 106, even if they are in an out of coverage state and none of them act as a SyncRef UE 1064.

[0211] The process of the provisioning phase described above may be repeated as required by tracker 102 or as directed by network 20 .

[0212] Figure 3 A signaling and processing diagram of the main usage or tracking phases according to an embodiment is schematically shown.

[0213] After completing the provisioning process, the tracker 102 initiates a master use phase (MUP) in step S301 and may start contact tracing in several modes, which may include a standalone mode (activatable only in the tracker's in-coverage state) and a cluster mode (activatable in the tracker's in-coverage state or out-of-coverage state).

[0214] In step S302, the already provided tracker 102 wakes up (enters the wake-up period) and senses any synchronization signal (SYNC) in its network environment in step S303. Based on the sensing step S303, the tracker 102 determines in step S304 whether it is in the coverage area of ​​the network (NW) 20 (in-coverage state).

[0215] If yes, the tracker 102 may determine in step S305 whether it is set to a standalone mode (SAM) or a clustered mode (CLM).

[0216] If standalone mode is activated or if step S305 is skipped, the process branches to step S307, where tracker 102 may send (report) its unique ID and optional metadata to network 20, or send (report) its unique ID and optional metadata to another device that may forward information to the network via D2D communication, enter a sleep cycle (period) set during the provisioning phase and / or updated by the network during the main use phase, and listen for a received unique ID during a wake-up cycle (period), whereby sleep and wake-up (S / W) timing as well as synchronization and resource allocation may be handled by network 20 based on existing protocols, e.g., as initially described.

[0217] In some embodiments, the tracker 102 may broadcast its unique ID during a wake-up period to coordinate communications using an existing D2D protocol (e.g., as initially described), using one of the available synchronization signals provided by the network 20. It may also listen for received IDs of other trackers, and may store each received ID with a timestamp, and may additionally store an estimate of the received signal strength of the D2D transmission.

[0218] Optionally, the tracker 102 may tag the received ID with additional ranging information as well as or in lieu of received signal strength (RSS). This may include two-way ranging techniques to associated trackers (e.g., as initially described). This option is expected to provide better ranging accuracy for each tracker at the expense of potentially increased power consumption. Optionally, the tracker 102 may advertise its two-way ranging capability as part of the metadata it transmits so that other trackers can attempt two-way ranging only to other trackers known to be capable of two-way ranging. For example, tagging the received ID may be accomplished by tagging the received ID information with metadata, where the metadata may be additional ranging information or additional RSS / RSI / RRSP information, or both.

[0219] Optionally, each tracker 102 may perform RF signal measurements or process received MIB / SIB / sidelink synchronization signal / PC5 ​​discovery messages and may include information such as cell ID, tracking area identifier (TAI), RSRP of neighbor cells, layer 2 or other identifiers received via PC5 discovery messages and / or signal strength of sidelink synchronization signal / PC5 ​​discovery messages and / or signal strength of different beams used / received from access devices or other trackers (e.g., as indicated by signal synchronization block (SSB) index) and / or information about which beam has the highest signal strength as part of the information shared with other trackers. This information may be sent to the network and considered in the network-side model 202 to locate the tracker.

[0220] Optionally, the tracker 102 may also listen for commands from the network 20 or the network side model 202 during its wake-up cycle. The network side model 202 may receive the tracker ID and metadata from the network 20 in step S312, and if necessary, may instruct the tracker 102 to increase the tracking range (TRR), change the sleep / wake cycle (S / W), and / or join a cluster (CL) in step S313.

[0221] Optionally, the network 20 can also set (selected or all) trackers to listening mode. In this mode, the tracker will wait for a request to be received and reply with its unique ID.

[0222] Trackers directly connected to the network 20 may forward the request to other out-of-coverage trackers.

[0223] In an embodiment, during a portion of the wake-up cycle, or optionally during a dedicated wake-up cycle that may be reserved for uplink communications with the network 20, the tracker 102 may report data to the network 20 (e.g., in step S307), which may include its own unique ID, the D2D transmit signal power used by the tracker 102 during the last wake-up cycle (i.e., the tracking range of the tracker, which may be recorded for each individual transmission if the power varies during the wake-up cycle), its own location (if available) (e.g., via GNSS), and at least one of any received unique IDs and signal strengths and metadata linked to those transmissions.

[0224] In one embodiment, for example in step S307, the tracker 102 may report all unique IDs and associated signal strengths and / or metadata observed since the last known and / or confirmed network contact (whether one wake-up cycle or several wake-up cycles). The unique IDs may be timestamped so that the network-side model 202 can calculate the order in which they were received.

[0225] Alternatively, the tracker 102 may report only those unique IDs from a certain number n of the last wake-up cycles or a certain number m of unique IDs received most recently (where n and m may be defined according to optimizing memory usage and location certainty in the network-side model 202 ).

[0226] In one embodiment, the fraction of wake-up periods used for network reporting in step S307 may initially be set to 100% or any other fraction. As the network-side model 202 increases its position certainty of the trackers, it may instruct them to modify (i.e., reduce) this fraction to save power by limiting long-distance transmissions per unit time (i.e., it instructs to reduce the transmit power of the unique ID transmission).

[0227] In one embodiment, the fraction of the wake-up period used for network reporting in step S307 may also be modified by the tracker itself. For example, in the event that the tracker does not receive a new unique ID (indicating a possible static location or cluster membership) during the wake-up period, it may optionally reduce its network reporting fraction to save power (in this case, the network 20 and / or the local tracker 102 may be configured to orchestrate clustering, as described later).

[0228] It is to be noted that if a tracker does not receive a new unique ID, but only receives a subset of known unique IDs, the tracker may report one or more previously known unique IDs as lost, as this may be an indication to the network 20 that the trackers with these unique IDs are now in a different location, or no longer have battery power, or are in a different (radio) environment, or are now out of coverage, etc.

[0229] In one embodiment, for example in step S307, the tracker 102 may report only newly observed or unobserved IDs and associated signal strengths and / or metadata since the last known and / or confirmed network contact. To this end, the tracker 102 may retain information about a list of other trackers previously discovered and / or information about which trackers have already reported to the network. This may reduce the amount of data or the frequency with which data needs to be sent to the network. At some point in time, the network may require the tracker to report all other observed trackers in order to update / refresh information known to the network or application, and / or to check whether all trackers are considered (e.g., in the network model).

[0230] In a further embodiment, the network or cluster head may send information about all tracker IDs currently considered by the network model or application and / or as part of the cluster, possibly also information about the time when the tracker ID was last seen / reported. Each tracker may decide based on this information whether it needs to report the tracker ID (again). The decision may also be based on a preconfigured time limit or number of cycles and / or a (maximum) change / variation of signal strength or a (maximum) range / positioning change, for which it is OK to no longer report the tracker ID.

[0231] The network 20 passes the received unique ID and associated metadata as input to the network-side model (step S312). In step S314, the network-side model 202 uses this data to calculate updates (LU) of the continuous estimate (approximation) of the location of each tracker (e.g., asset tracker group 10) and updates the tracker location database.

[0232] Optionally, if the protected (eg, encrypted) unique ID and associated metadata are decrypted by the network-side model 202 , for example, the network 20 may also pass the protected (eg, encrypted) unique ID and associated metadata to the network-side model 2020 .

[0233] In step S314, the network-side model 202 may use various techniques to estimate the position of each tracker based on the (partial) position data stored at the previous time step and the newly reported unique ID received from each tracker. For example, in the case where the tracker has a well-known position (e.g., due to having GNSS hardware or due to a well-characterized position calculated by the network-side model 202 at the previous model time step or configured by the installer), it may be marked as an anchor tracker or anchor node. Then, any tracker whose unique ID is received by the anchor tracker may be marked as being within the radius given by the D2D tracking range of the relevant transmission.

[0234] Optionally, the network-side model may search for data of the same transmission received from the relevant counterparty trackers to identify matching unique ID transmissions from the same interaction. This may give additional information about the true range of the trackers during the transmission event. For example, if two trackers use different transmit powers corresponding to different tracking ranges, and one tracker can "see" the other tracker, but not vice versa, the uncertainty of the true range (as encoded in the network-side model 202) can be reduced.

[0235] In the case of variable transmit power, the true tracking range can be calculated by the ratio between the used (known) transmit power and the (measured) received power received by the counterparty. To this end, the tracker may append to each transmission data indicating the transmit power it used, and / or the receiver may include data indicating its received signal strength along with the reported received unique ID.

[0236] If the tracker 102 is not an anchor (ie, has no well-known ground truth location), any received unique IDs reported by the tracker 102 in step S307 may be used as additional constraints on the location via their relationship to anchor trackers, other trackers, and / or associated tracking ranges.

[0237] Optionally, the network-side model 202 may also use additional features of the contact tracking data to update its position estimate. For example, in a situation where two trackers track each other multiple times during a wake-up cycle but the apparent tracking range keeps changing, the network-side model 202 may infer that the associated trackers are moving (relative to each other). In this case, the network 20 may optionally instruct one or both of the trackers to take motion-related actions (e.g., actively search for another tracker after a period of time when it is expected to still be in range given the estimated velocity).

[0238] In the event that the contents of the tracker's unique ID memory are substantially similar in repeated reports, the network-side model 202 can infer that the tracker is always co-located. This may apply to fixed trackers (e.g., in storage) or trackers in motion (e.g., fixed to cargo in the same truck).

[0239] As another option, the network-side model 202 may also use additional features of the reported metadata to enhance its location estimate, where available. Examples may include internal sensor data from a tracker (or co-located tracker) indicating motion, temperature changes, changes in received signal strength of network transmissions (including transmissions from different cells within a cellular network), etc. Changes measured by such internal sensors that meet preconfigured thresholds may trigger a change in the frequency of ID reporting, may trigger a change in the tracking range, or may trigger a connection to the network to request an update of the sleep / wake period or an update of the tracking range or other parameters, or may trigger the device to enter a provisioning mode.

[0240] By repeatedly performing at least some of the above-described additional evaluation options for all available trackers at each time step, network 20 may further constrain the uncertainty of its estimated position, such as via multilateration techniques using tracking ranges and received unique IDs.

[0241] In one embodiment, the network-side model 202 (or the cluster head 1062 when the tracker 102 is set to cluster mode, as described later) can be configured to further analyze the estimated power consumption of each tracker by instructing the tracker to change the tracking range, uplink communication frequency, and / or sleep / wake period for subsequent transmission when necessary (e.g., in step S313) to attempt to optimize both the power consumption and overall position certainty of all trackers.

[0242] Examples of actions that allow the network-side model to reduce tracker energy consumption include increasing sleep and reducing wake-up periods (this can be used, for example, in situations where the network 20 has good knowledge of a given tracker because it has been tracked by multiple anchor trackers at previous time steps).

[0243] As previously explained, a tracker 102 may join a cluster when instructed by the network 20, because it is out of coverage and has only line of sight to the cluster, or for other reasons (e.g., if a group of trackers is known to stay together during expected use, an installer may initially provision a group of trackers to form a cluster, with the advantage that the group of trackers will continue to operate even if the group of trackers moves to an out of coverage area).

[0244] When it is determined in step S305 that the tracker 102 is in cluster mode, the tracker 102 may act as a SyncRef UE 1064 of the cluster 106 and broadcast a synchronization timing or reference signal (SYNC) during each wake-up cycle in step S309 that is used by other cluster trackers 1066 of the cluster 106 to coordinate communications.

[0245] In step S310, cluster trackers 1066 transmit (report) their IDs and metadata to other cluster members, and transmit the received IDs and metadata to cluster head 1062. One of cluster trackers 1066 also assumes the role of cluster head (CLH) 1062, e.g., storing the accumulated unique ID and metadata of cluster 106 to report to network 20 in step S311 when possible (available). These can be the same or different trackers.

[0246] In an embodiment, initially at cluster provisioning, the network 20 (or the installer's UE 40) may act as both a SyncRefUE 1064 and a cluster head 1062. Subsequently, the selection of the role of the SynRef UE 1064 and / or the cluster head 1062 may be made by the cluster trackers 1066 of the cluster 106. In an example, the selection may be based on at least one of the availability of an external source of precise timing (e.g., GNSS), the highest remaining battery life and / or the lowest average transmission power of the remaining cluster trackers 1066 of the cluster 106, a random decision (a fallback option with the risk that the shared internal clock of the cluster may drift from the network time / clock). In other examples, the selection may (also) be based on the highest predicted "on" lifetime given the status of all cluster trackers 1066, including aspects like battery charge / capacity / lifetime status, but also the status of energy harvesting functionality if available (e.g., a tracker with active solar panels that have been generating energy for some hours is a good candidate). To this end, a cluster tracker 1066 may send information about its energy-related status to other cluster trackers 1066 .

[0247] When the cluster 106 is in partial network coverage, it may be advantageous for the SyncRef UE 1064 and cluster head 1062 to become the cluster tracker 1066 with network access (because the cluster 106 can then maintain contact and synchronization with the rest of the network 20).

[0248] In an example where only one cluster tracker 1066 of a cluster 106 has network coverage, that cluster tracker 1066 can act as both a SyncRef UE 1064 and a cluster head 1062. In another example, where more than one cluster tracker 1066 has network coverage, the selection can be random, or based on properties of the cluster trackers in coverage, such as remaining battery life or other criteria described above. In particular, for the role of cluster head 1064, the cluster tracker 1066 with the highest remaining battery life (or other capacity such as storage) can be selected.

[0249] In one embodiment, the cluster tracker 1066 may append data to its metadata broadcast to the cluster head 1062 in step S310 to indicate its signal status relative to the network (e.g., the measured RSSI of the signal received from the gNB) to facilitate the above selection.

[0250] In one embodiment, a cluster tracker 1066 that has become a cluster head 1062 or has decided to become a cluster head 1062 broadcasts this information to other cluster trackers 1066 in the cluster 106. Another cluster tracker 1066 currently serving as a cluster head 1062 may continue to do so or stop serving as a cluster head 1062 based on the information received from the new cluster head 1062. A cluster head 1062 or a cluster tracker 1066 that has decided to become a cluster head 1062 may report their cluster head role to the network 20, possibly along with additional information, such as energy status information or signal strength information. The network 20 may decide to select one of the cluster heads 1062 as the head of the cluster 106, and may notify the cluster head 1062 of the decision, and / or may notify other cluster heads 1062 to stop serving as cluster heads 1062.

[0251] In an embodiment, the two roles of SyncRef UE 1064 and cluster head 1062 may rotate between cluster trackers 1066 of the cluster 106 with each wake-up cycle, for example, based on data transmitted during the previous wake-up cycle or based on a preset schedule.

[0252] In the event that no external timing source (e.g., GNSS) is available, the timing of subsequent wake-up cycles may be provided by the internal clock of the SyncRefUE 1064 during intermediate sleep cycles. In this case, the wake-up time of each sleep / wake-up cycle may be defined to be of sufficient length to compensate for the expected clock drift of the cluster trackers 1066. For example, for cluster trackers 1066 where the worst case clock drift is + / - 1 per day, for a 6h sleep cycle, a wake-up period of 0.5s plus one transmission time may ensure that the wake-up periods of the two worst performing cluster trackers 1066 overlap by at least one transmission time (although for practicality, the wake-up periods may be longer than this). This may require, for example, configuration of relevant parameters (e.g., clock drift) by the network 20 on the SyncRef UE 1064. Such configuration may be policy-based.

[0253] In each wake-up cycle, the cluster trackers 1066 of the cluster 106 wake up and send their IDs, while listening for any received IDs in step S310, similar to step S307 in standalone mode. In addition to the IDs, the cluster trackers 1066 may transmit metadata containing, for example, their remaining battery life (optionally, this metadata may be transmitted only on a certain portion of the wake-up cycle). Such metadata may be used to assign the role of the cluster head 1062 to one of the cluster trackers 1066 within the cluster 106.

[0254] As described above, the role of the cluster head 1062 may rotate after each wake-up cycle or less frequently as desired. For the first wake-up cycle, the cluster head 1062 may initially be the same cluster tracker as the SyncRef UE 1064. In subsequent wake-up cycles, the cluster trackers 1066 may advertise their availability and / or suitability for the role of the cluster head to the network 20 via metadata (e.g., due to high remaining battery life), or alternatively, the current cluster head 1062 may make that determination.

[0255] If the current cluster head 1062 selects the expected next cluster head during the wake-up cycle, and if and only if a positive response confirming the role change is received, the roles may rotate at the next wake-up cycle. The selection may be based on information collected and shared by potential cluster head candidates about their ability to reach all members in the cluster 106. In this way, it may be possible to have a high degree of certainty that there is always exactly one cluster head 1062.

[0256] In some scenarios, some cluster trackers 1066 may never be elected as cluster heads 1062. However, the above process allows for at least some rotation or sharing of roles within a cluster 106.

[0257] In various embodiments, resource blocks used for out-of-coverage D2D cluster transmissions may be selected from a set of default values ​​reserved in the standard (similar to the previously referenced semi-persistent scheduling of Mode 3 or 4 out-of-coverage D2D).

[0258] The transmission of the received unique IDs by the trackers in steps S307 and S310 in each wake-up cycle may be implemented by forwarding a list of received unique IDs (each unique ID is marked with a timestamp) and their own metadata to the network 20 or cluster head 1062, respectively, where the list of received unique IDs and timestamps is stored together with the metadata from each tracker. Optionally, in scenarios where out-of-coverage states are frequently expected for the cluster 106, the stored IDs may be stored by all cluster trackers 1066 of the cluster 106, not just the cluster head 1062. This may enhance the likelihood that they are received by the network 20, where the cluster trackers 1066 may move independently.

[0259] Optionally, all cluster trackers 1066 of a cluster 106 (or at least the SyncRef UE 1064 and the cluster head 1062) may be forced (e.g., by the network 20 or the installer's UE 40) to wake up by default at a certain period (e.g., once a day or longer) and send their ID and metadata reports using their maximum D2D tracking range. This option may be advantageous for finding any 'lost' cluster trackers 1066 that may have moved out of the tracking range of their cluster 106, and for enabling out-of-coverage provisioning for new trackers. Such new or lost trackers may thus find the cluster head 1062 with a higher probability and be able to (re)join their cluster 106.

[0260] When in coverage, the cluster head reports the accumulated unique ID, timestamp and metadata to the network 20 in step S311. The network side model 202 uses the information from the cluster head 1062 to update its position estimate, as in standalone mode.

[0261] In one embodiment, the network-side model 202 also determines whether it is advantageous to maintain or interrupt the cluster 106 or to modify the tracking range or sleep / wake cycle, such as in standalone mode (eg, step S313 ).

[0262] In addition, in various embodiments, such a decision may be made locally by the cluster head 1062 based on a policy stored locally or deployed by the network 20, and the relevant new parameters (e.g., changed tracking range, role of SyncRef UE, sleep / wake cycles, etc.) may be transmitted to the cluster tracker 1066 and / or SyncRef UE 1064 in step S308.

[0263] For example, if the cluster tracker 1066 is using high transmission power to exchange reports and / or the cluster head 1062 or SyncRef UE 1064 is transmitting with too much power, the cluster head 1062 can be configured to decide that it is advantageous to split the cluster 106 to form a new cluster, where the two clusters can then have lower transmission power (i.e., shorter tracking range). The decision can be based on the transmission power required for the signal of the SyncRef UE to reach all cluster trackers 1066 of the cluster 106. In this case, the cluster head 1062 can be configured to transmit to one of the cluster trackers 1066 the cluster head and SyncRef UE that need to act as a new cluster during the subsequent wake-up cycle. The selection of the cluster tracker 1066 can be based on at least one of the low received signal strength of the candidate cluster tracker (meaning the distance from the existing cluster head 1062 is far), battery life, and other resources. The new cluster then starts itself and operates as described above.

[0264] In a second example, the cluster head may extend the sleep period based on low or no changes in cluster membership and / or low mobility of the cluster 106 as a whole. This may be done, for example, if the cluster 106 has a maximum size (e.g., because otherwise the messages become too long). The decision may be based on the number of cluster trackers 1066 in the cluster 106.

[0265] In the event that modifications are required (as described above), the network 20 may send the desired power and timing parameters to the cluster head 1062, or for locally applied changes, the cluster head 1062 may send the relevant new parameters to the cluster members during a subsequent wake-up cycle and apply the settings during a subsequent or later wake-up cycle.

[0266] In one embodiment, when in coverage, the cluster head 1062 may not report the accumulated unique ID in step S311, but send the difference of the accumulated unique ID compared with the previous wake-up period (eg, lost ID and / or new ID) to reduce communication overhead.

[0267] In an example, a dictionary may be used that maps potentially long unique IDs to shorter cluster-specific IDs or cluster-head-specific IDs. For example, if the cluster-head 1062 receives unique IDs "0xAAAA AAAA" and "0xBBBBBBBB" in a first wake-up cycle, it may report "0x00" and "0x01" in a second wake-up cycle (where "0x00" and "0x01" are two short binary cluster-specific IDs that map to hexadecimal IDs "0xAAAA AAAA" and "0xBBBB BBBB", respectively).

[0268] The thresholds used for such decisions may be influenced by policies hard-coded into the tracker or deployed to the tracker via the network 20 .

[0269] For example, such a policy may define reducing the D2D tracking range by reducing the required D2D transmission power of the tracker, and this may be done, for example, if the tracker receives more ID transmissions from peer trackers than required for a proper position estimation.

[0270] As another example, a dynamic cluster may be formed where the network 20 identifies that a group of trackers are persistently co-located and / or data from a network-side model indicates or estimates that this is unlikely to change before the next wake-up cycle (e.g., due to no relative tracker motion), for example, by instructing all but one of the trackers to suspend uplink communications to the network 20, while the remaining trackers report their contact tracking history (list of received IDs) as previously described. The trackers themselves may also optionally make this decision based on receiving the same unique ID over several wake-up cycles (which may indicate a static state, as previously described). The tracking range of the cluster 106 may be calculated by the network 20 (or proposed by the cluster head 1062) and transmitted to the cluster trackers 1066. The sleep / wake-up cycle may remain unchanged, or the sleep cycle may be extended in the case where the same group of trackers remain co-located for a long time, because the risk of tracker loss is low. This allows the trackers to save power by collectively reducing uplink transmissions without explicitly entering cluster mode (which may require additional resources due to the need for the SyncRef UE 1064 to broadcast synchronization signals).

[0271] As a further example, a dynamic selection of which tracker to act as the SyncRef UE 1064b and / or cluster head 1062 may be made for an existing cluster 106. The selection may be done independently by the cluster trackers 1066 of the cluster 106 based on a deployed policy, or may be done by the network 20 based on existing reports of the cluster trackers 1066. Alternatively, the selection may be based on at least one of the mutual locations of the cluster trackers 1066 of the cluster 106, the location of the cluster 106 relative to the associated gNBs of the network 20, and the coverage status of the cluster 106. For example, where a cluster tracker 1066 is known to be located in the middle of a cluster 106, it may reach all other cluster trackers 1066 within the cluster 106 with lower transmit power (and therefore less energy consumption). Therefore, selecting the most appropriate cluster tracker is relevant.

[0272] In cluster mode, this policy-based optimization can also be initiated by the cluster head 1062. In this case, in addition to the metadata normally attached to the report transmissions of the cluster members, the cluster tracker 1066 can also attach data indicating the signal strength to the network (e.g., RSSI). Similar to the network 20 described above, the cluster head 1062 can use this data plus the received strength of the transmissions within the cluster (as a mutual position indicator) as input to the decision.

[0273] By way of example, the cluster head 1062 may select the most appropriate cluster tracker to act as the SyncRef UE 1064 or a new cluster head in a subsequent wake-up cycle by causing all cluster trackers 1066 to transmit a synchronization reference signal and then each broadcast the received measured power of the received synchronization reference signal. The cluster head 1062 may then select a cluster tracker 1066 whose synchronization reference signal is received most by all other cluster trackers (i.e., the received signal strength is highest for the cluster tracker in the cluster that receives the synchronization reference signal from a given cluster tracker with the lowest received power).

[0274] In one embodiment, the selection of the most appropriate tracker to act as the cluster head 1062 or SyncRef UE 1064 may also or exclusively be based on the energy cost of sending / receiving messages to / from the network 20 (e.g., to / from the nearest gNB of the network 20). This may be relevant when the cluster 106 is in partial coverage. For example, if the SyncRef UE 1064 loses connection with the network 20 (e.g., because it is far away from the (assigned) gNB), in some scenarios, cluster trackers 1066 on the edge of the cluster 106 may remain in coverage. As previously described, it is advantageous for these cluster trackers 1066 to assume the role of the SyncRef UE 1064 and / or cluster head 1062. This may be advantageous because it allows the cluster 106 to maintain network contact through the cluster head 1062. However, in the event that this results in a high required transmit power within the cluster 106 as a whole, the cluster head 1062 may attempt to reduce the transmit power within the cluster (i.e., cluster-wide).

[0275] In an embodiment, the cluster head 1062 may decide to select a tracker (e.g., cluster tracker 1066, standalone tracker 102, or isolated tracker 104) to act as the cluster head 1062 and / or SyncRef UE 1064 that has both network coverage and the lowest average transmit power to the remaining members of the cluster 106. The decision may be based on the received signal strength of the received synchronization reference signal. A tracker that receives a synchronization reference signal with high power will select a lower transmit power, and a tracker that receives a synchronization reference signal with low power will select a higher transmit power.

[0276] As another option, cluster head 1061 may decide to split cluster 106 into two or more clusters (which may result in, for example, at least one in-coverage cluster and at least one out-of-coverage cluster).

[0277] The above decision can be based on the policy deployed by the network, balancing power usage against the risk of tracker or cluster loss.

[0278] Examples of actions that allow the network side model 202 to increase position certainty (on average) may include at least one of: increasing the D2D tracking range (this may be done globally, or for specific trackers suspected of being close to a second tracker that is out of coverage or has insufficient resources (in cluster mode, the cluster head 1061 may also initiate this optimization)), reducing sleep cycles and / or increasing wake-up cycles (because more measurements may be made and the risk of tracker loss that may occur during sleep periods due to tracker motion is lower (in cluster mode, the cluster head 1061 may also initiate this optimization)), breaking the cluster and controlling the tracker to revert to (pure) standalone mode.

[0279] Therefore, the network-side model is configured to optimize the tracking system for low power usage while improving positioning accuracy only for those trackers that need it.

[0280] In an embodiment, updated settings and configurations for implementing an optimized tracking system may be transmitted (securely) to the tracker by the network 20. To achieve this, the network 20 (ie, the specific element / function, if it) may have the authority to make these updates. .

[0281] In various embodiments, in addition to the above optimizations, the network-side model 202 can be configured to instruct a group of trackers (e.g., cluster trackers 1066, standalone trackers 102, or isolated trackers 104) to enter cluster mode in some scenarios as described below. Trackers can also enter cluster mode on their own based on policies deployed by the network to the trackers indicating relevant conditions / situations.

[0282] The advantage of cluster mode is that it works in an out-of-coverage state, and therefore the network-side model 202 will be primarily based on the decision of whether a signal loss is possible or expected for a given tracker or tracker group. This can be estimated, for example, based on their relative motion or position near the cell border or based on the network-RSSI or other values ​​they report. The tracker can enter cluster mode by itself, for example, when the RSSI value is below a threshold. Alternatively, the decision can be made locally by a group of trackers in response to a policy deployed to them via the network 20. This may be the case especially during the provisioning step (as described herein in conjunction with the cluster provisioning mode), where details indicating the high mobility possibility of the tracker are provided, for example, by the installer's UE 40. When in cluster mode, the tracker can attempt to join any nearby cluster 106, as described herein in conjunction with out-of-coverage provisioning. Once the tracker has successfully joined the cluster 106, the cluster head 1061 can use the RSSI data attached to its metadata between the network 20 and each cluster tracker 1066 of the cluster 106 to decide whether to remain in cluster mode or interrupt the cluster 106 for each wake-up cycle.

[0283] A secondary reason to enter cluster mode may be because the known or expected future location of the tracker may place it within range of one or more out-of-coverage isolated trackers 104, such that having a SyncRefUE signal at that location may enable the network 20 to discover the one or more out-of-coverage isolated trackers 104. This may be the case if the tracker is at a cell boundary or it is moving in a predictable or known trajectory (e.g., attached to a vehicle whose route planning is known and reported as part of the metadata).

[0284] A third reason to enter cluster mode is that it potentially allows energy savings by minimizing remote transmissions from cluster members (as described above). This decision can be made centrally by the network side model, or locally by any cluster head 1061 or tracker based on the content of the ID it receives and its coverage status for the network 20.

[0285] In one embodiment, upon determining that one or more trackers should enter cluster mode, the network-side model 202 may instruct those trackers to enter cluster mode via the network 20, where the network 20 may be configured to initially act as a cluster head 1062 and a SyncRef UE 1064 (in this case, the synchronization reference signal may be a normal synchronization signal of the network, rather than a sidelink / D2D synchronization signal that the SyncRef UE 1064 would use when in an out-of-coverage state). Subsequently, the SyncRef UE and cluster head roles may be shared among members of the cluster 106 based on at least one of battery life, other available resources, and (possibly) mutual location, as described above and below herein.

[0286] The triggering of the switch from the network provided synchronization reference signal to the locally generated (i.e., by the SyncRef UE 1064) can be initiated immediately (i.e., on the second wake-up cycle, when the network 20 has provided the synchronization reference signal during the first wake-up cycle), or when any one of the clusters (heads) moves out of coverage (which may be advantageous by waiting until a risk of coverage loss has been detected, which helps save power in the tracker by not requiring the SyncRef UE 1064 until the latest possible moment, but may result in an increased risk of the entire cluster 106 losing synchronization if the entire cluster 106 all leaves coverage at the same time without a locally defined SyncRef UE 1064).

[0287] The decision between the two options described above may be made by the network 20 or by any of the cluster trackers 1066 of the cluster 106. For example, the network-side model 202 or any individual cluster tracker 1066 of the cluster 106 may initiate a switch to a locally generated synchronization reference signal on a subsequent wake-up cycle, for example by setting an appropriate logical flag. This allows individual trackers to be detached from network control in a safe manner (i.e., without the risk of losing the entire cluster 106 if all trackers suddenly move out of coverage).

[0288] In one example, the tracker may determine that a local synchronization reference signal would be advantageous based on at least one of a detected low RSSI (indicating a location near a cell edge), detected local movement, and detected configuration details indicating a risk of sudden movement (e.g., for a pallet on a truck).

[0289] Back to Figure 3 During the main use phase of , when the tracker determines in step S304 that it is outside the coverage area of ​​the network 20, it may check in step S306 whether it can start the cluster mode (eg, based on the above criteria) or needs to remain isolated (ISO).

[0290] In the first case, the process branches to step S309 where the out of coverage tracker 102 becomes a cluster tracker 1066 and receives a synchronization reference signal from the SyncRef UE 1064 of the cluster 106 .

[0291] In the latter case, or if step 306 is skipped, if the out of coverage tracker 102 does not receive other tracker IDs in step S306 during the wake-up period, it determines that it is an isolated tracker (ITR). It then attempts to contact the SyncRef UE 1064 of the network 20 or a nearby cluster in step S315 (CNT). When network contact has been established, the isolated tracker 104 returns to the provisioning phase (PP) in step S316 and re-attempts provisioning, as described above with reference to Figure 2 described.

[0292] However, if such an isolated tracker 104 can (again) determine that it is within the coverage range, the process branches to step S305 or S307 and the isolated tracker 104 can be set to a standalone mode.

[0293] Figure 4 The flowchart schematically shows the sub-processes of the provisioning phase (steps S401 to S416) and the main use phase (steps S421 to S435) according to the corresponding embodiment, which can be executed by the processing unit of the tracker (TR). Note that the functions and parameters described in conjunction with steps S401 to S435 include the above combined Figure 2 and Figure 3 All relevant and / or applicable options and examples are described.

[0294] In step S401, when the tracker is first powered on and enters provisioning mode, an initial provisioning phase (I-PP) begins.

[0295] In step S402 , the tracker attempts to contact the network via existing protocols and / or attempts to find other nearby trackers in the cluster.

[0296] In step S403 (IC), the tracker determines whether it is in the coverage area of ​​the network. If so, it determines in step S404 whether it has found a nearby cluster. Similarly, if not, the tracker determines in step S405 whether it has found a nearby cluster.

[0297] If the tracker determines in step S404 that no nearby clusters are found, the process branches to step S406 and the tracker transmits its unique ID (and optional metadata) to the network (NW).

[0298] Then, in step S407, the tracker waits until it receives provisioning data (PD) from the network which may include nearby clusters if available.

[0299] In a subsequent step S408, the tracker starts a Contact Tracing Broadcast (CT-BC) using the data provided by the network.

[0300] In optional step S409 , the network may instruct the tracker to immediately join any suitable cluster.

[0301] Otherwise, if the tracker determines in step S404 or step S405 that a nearby cluster has been found, the process branches to step S410 (when the tracker is within the coverage and range of the cluster), and the tracker can select network provisioning (NWP) or cluster provisioning (CLP).

[0302] Then, the tracker communicates with the SyncRef UE of the cluster to receive a synchronization reference signal (SYNC) from the SynRef UE in step S411 and receives a sleep / wake timing (S / WT) from the cluster head in step S412.

[0303] In step S413, the tracker transmits its unique ID to the cluster head.

[0304] Finally, in step S414, the tracker joins the cluster and is provisioned.

[0305] Otherwise, if the tracker determines in step S405 that no nearby cluster is found, the process branches to step S415 and the tracker determines that it needs to be manually provisioned (MP) by an operator (e.g., via the installer's UE) or that it cannot be provisioned and retries (RP) the provisioning phase at defined intervals (or after a detected event such as motion).

[0306] In optional step S416 , the tracker may try to form its own cluster by becoming a SyncRef UE (SR-UE) and waiting until other trackers are found.

[0307] When the tracker is provisioned according to one of the above branches, the main usage phase (tracking) (MUP(TR)) may be started in step S421.

[0308] In step S422, the tracker enters an awake state during the wake-up period according to the supplied sleep / wake-up timing defining specific sleep and wake-up cycles, and the tracker attempts to synchronize (SYNC) with the network or determined local cluster.

[0309] Then, in step S423, the tracker determines whether it is in coverage (IC) of the network.

[0310] If yes, the process branches to step S424, where the tracker is based on the above combined Figure 3 Describes the criteria and options for determining whether it enters clustered mode (CLM) or standalone mode (SAM).

[0311] If the tracker selects standalone mode in step S424, the process branches to step S426, where the tracker broadcasts (TX) its unique ID (using, for example, via a local area protocol) and listens (RX) for received IDs and associated metadata.

[0312] Then, according to a preset schedule or network request, the tracker reports (REP) its received ID and related metadata to the network in step S427, so that the network-side model of the network can update its estimate of the location of all trackers with the newly received information from the tracker. Optionally, the update can be confirmed to the tracker in step S428 (UD L-EST).

[0313] In step S429, based on the position estimate generated by the network-side model, the tracker may optionally receive a request from the network to modify (MOD) its tracking range (TR) and / or update frequency (UF).

[0314] Otherwise, if the tracker selects cluster mode in step S424, the process branches to step S430, where the tracker can initially operate as both a Cluster Head (CLH) and a SyncRef UE (SR-UE), where the roles of Cluster Head and SyncRef UE can be distributed among cluster members over subsequent wake-up cycles to optimize energy usage.

[0315] In step S431 , the tracker and other cluster members continue local contact tracing (LOC CT) by trying to receive IDs from other trackers.

[0316] Optionally, when a local contact change is observed, the tracker in the initial role as the cluster head (or a newly selected cluster head) may actively search for any nearby trackers (SR TR) in step S432.

[0317] When in range of the network, a tracker in its initial role as a cluster head (or a newly elected cluster head (CLH) and / or any other tracker requested by the network) may report the accumulated ID history (IDH) in step S433.

[0318] The above steps S429 and S433 are followed by a common step S435 where the tracker position estimate is updated by the network-side model (and receipt may optionally be acknowledged to the tracker) and reported to appropriate downstream applications as required.

[0319] Otherwise, if the tracker determines in step S423 that it is outside the coverage area, the process branches to step S425, where the tracker determines that it is outside the coverage area, for example based on the above combined Figure 3 Describes the criteria and options to determine whether it enters Cluster Mode (CLM) or Isolation Tracker (ISO).

[0320] If the tracker selects the trunking mode in step S425, the process branches to step S430 and continues there.

[0321] Otherwise, if the tracker determines in step S425 that it is an isolated tracker, the tracker attempts to reestablish contact with the network (NW) or join the cluster (CL) in step S434, for example, as described above in conjunction with Figure 3 described.

[0322] Figure 5 An example of an asset tracking system with standalone mode and dynamic clustering according to an embodiment is schematically illustrated.

[0323] like Figure 5 As shown in the upper part of FIG, asset trackers 102 numbered 1, 2, and 3 are co-located with contact tracking range 52 within D2D tracking range (e.g., PC5 operating range) 502. Asset tracker 102 numbered 4 is outside D2D tracking range 502 but still within network coverage (e.g., Uu interface to gNB).

[0324] In step S501, the network (e.g., a network-side model) determines corresponding position estimates L1, L2, L3 of the positions of asset trackers 102 numbers 1 to 3 based on the broadcast IDs 1 to 3 of the asset trackers 102 and the metadata received at the gNB. However, since asset tracker number 4 is outside the D2D tracking range 52, it operates in a standalone mode and needs to report its ID via a separate transmission, while asset tracker number 1, which may act as a cluster head, may report the cumulative IDs of asset trackers numbers 1 to 3.

[0325] Then, in step S502, based on the received metadata (for example, as described above in conjunction with Figure 3 As described above), the network or cluster head calculates a new dynamic cluster with increased ranging power for contact tracking, and signals the increased ranging power to the cluster in step S503, so that the increased range 54 for D2D contact tracking is temporarily provided and the asset tracker 102 of number 4 is now located within the enhanced contact tracking range 54. As a result, assuming that the asset tracker 102 of number 1 acts as a cluster head, it receives IDs from all other asset trackers (i.e., numbers 2 to 4) and can report all IDs without the need for the asset tracker number 4 to report separately.

[0326] Figure 6A positioning system for an asset tracker according to an embodiment is schematically shown, which embodiment can be implemented independently or in combination with other embodiments. In this embodiment, it is necessary to determine the location of the asset tracker 102. To this end, the asset tracker 102 can send a message A (e.g., a broadcast message, or a sounding reference signal, or a measurement report) at a frequency F_A and a signal modulation / type M_A at a transmit power Tx_A at a time T_A, whereby the message may include an ID and possible other information provided by the asset tracker 102, such as information about the transmit power Tx_A (or other energy indicators indicating the energy of the transmitted signal), information about the frequency F_A used, information about the signal modulation / type M_A used, information about which codebook is used, the signal strength of the last received signal (e.g., RSRP), the time difference between the last received signal and the last transmitted signal or other measurement information, timing advance, location information, tag sighting report information and / or information about the discovered nearby gNB / UE / asset tracker 601 (_1..N) (e.g., the cell ID of the nearby base station or the ID received in the message from the nearby UE / asset tracker). The signal characteristics (e.g., transmit power Tx_A, frequency F_A, modulation M_A) and / or timing (e.g., time T_A) used to send message A can be based on an earlier configuration provided, for example, by the network or a nearby UE / asset tracker (e.g., cluster head). One or more nearby UE / asset trackers / gNBs 601 (_1...K) can receive message A and can determine the signal strength and / or angle of arrival of the received message A. This information can be used to determine the distance or (relative) location of the asset tracker 102. Figure 6As shown, based on the signal propagation characteristics of the signal used to send message A, the gNB / UE / asset tracker 601 (_1...K) may be located in range r1 (indicated by the inner circle). The nearby gNB / UE / asset tracker 601 (_1...K) that has received message A may send a message N to the network (e.g., to a location service) or to a device (e.g., cluster head, anchor node) that may perform location services to report that it has received message A from the asset tracker 102, whereby the message N may include information received from the asset tracker 102 and / or information that it has determined based on receiving message A from the asset tracker 102 (e.g., signal strength, angle of arrival, (relative) position). The nearby gNB / UE / asset tracker 601 (_1...K) may additionally or alternatively send a message X to the asset tracker 102 indicating that it has received message A. Message X may include information about the gNB / UE / asset tracker 601 (_1…K) that has received message A, such as an identifier of the gNB / UE / asset tracker 601 (_1…K), the signal strength (e.g., RSRP) of the received message A, the time difference between receiving message A and sending message X, or other measurement information, location information related to the asset tracker 102 or the gNB / UE / asset tracker 601 (_1…K) that sent message X, tag sighting report information, or information about other discovered nearby gNB / UE / asset trackers. Based on receiving one or more messages X from a nearby gNB / UE / asset tracker 601 (_1…K) and / or information received in message X and / or configuration information (e.g., a preconfigured schedule for sending messages, possibly together with a transmit power to be used and / or a policy / criteria / condition for when to send these messages (e.g., if the RSRP reported in message X is below / above a configured threshold, or the number of messages X is above / below a certain threshold)), the asset tracker 102 may send an additional message B (possibly with similar or identical fields / payload as message A or identical to message A) with transmit power Tx_B at frequency F_B and signal modulation / type M_B at time T_B, whereby the transmit power Tx_B is different from the transmit power Tx-A and / or the frequency F_B is different from the frequency F_A and / or the modulation M_B is different from the signal modulation / type M_A. Assuming that message B is sent with different characteristics (e.g., lower transmit power or higher frequency or using a different codebook), it also affects the signal characteristics of message B, and thus message B may be received by additional or fewer gNB / UE / asset trackers 601 (_1...M) nearby. Figure 6As shown, based on the signal propagation characteristics of the signal used to send message A, the gNB / UE / asset tracker 601 (_1...M) can be located in range r2 (indicated by the dashed line). The gNB / UE / asset tracker 601 (_1...M) that receives message B can send message O (having similar or identical fields / payload as message N) indicating that it has received message B from asset tracker 102, and can send message Y (having the same or similar fields / payload as message X) to asset tracker 102. Based on messages N and O received from the gNB / UE / asset tracker 601 that has received message A and / or message B, a network (e.g., location management function) or device that supports location services can determine / estimate the location of asset tracker 102. To this end, it may use the fact that a certain gNB / UE / asset tracker received message A but not message B, or vice versa, to include / exclude an area where the asset tracker 102 may reside (e.g., if the distance / angle / position estimate itself is not accurate enough, then given the information provided, multiple potential locations may be valid, in which case one or more potential locations may be excluded / included by using information about the area where the asset tracker may or may not reside). Additionally or alternatively, the asset tracker 102 may use messages X and Y received from nearby gNB / UE / asset trackers 601 to determine its own location, which it may use when sending further messages to the network, and / or change its configuration (e.g., transmit with less power to reduce the contact tracing range). Note that messages A and B need not be the only two messages. They may be part of a sequence of messages, possibly each with different signal characteristics (such as different transmit power or using a different codebook) to more accurately estimate the location of the asset tracker 102. In Figure 6In the example represented in , where r2 is greater than r1, the fact that message A is received by gNB / UE / asset tracker 601_1 and message B is received by gNB / UE / asset tracker 601_4 can be used by the location service to determine that asset tracker 102 is located between 601_1 and 601_4, but closer to 601_1 than 601_4. Furthermore, the location service can use the fact that message B is received by gNB / UE / asset tracker 601_4 but not 601_6 to determine that asset tracker 102 is not located within range r2' of 601_6, which may be the same or similar to r2, with some uncertainty margin (e.g., due to signal fluctuations), so the area indicated by the dashed blue circle with range r2' can be used to exclude potential locations of asset tracker 102. Given that signal ranges may fluctuate given the propagation characteristics of the environment, the calculation / estimation of ranges r1, r2, r2' needs to be performed with some error margin. Additionally or alternatively, the asset tracker 102 or the gNB / UE / asset tracker 601(_1…N) may send a series of messages to increase the reliability of range determination and / or gain more insight into fluctuations. Additionally or alternatively, distance and / or angle information derived from the timing of the messages may be used to more accurately calculate the range. Additionally or alternatively, the gNB / UE / asset tracker 601(_1…N) may send a signal / message with the same signal characteristics to the asset tracker 102 (e.g., resending the same message A or B that it has already received) to check whether the asset tracker 102 can receive the signal / message with sufficient quality / signal strength to check whether the asset tracker 102 is at the edge of the signal range or relatively close, as signal fluctuations may be most influential at the edge of the signal range.

[0327] In an embodiment variation, the asset tracker 102 may send a series of messages, each with a set of signal characteristics whereby the expected range (e.g., based on a propagation model, which may be based on theoretical assumptions, or based on / adapted to measurements received from a device) is less than or equal to (with some preconfigured margin) the previous message in order to minimize the number of gNB / UE / asset trackers 601 (_1 ... M) that may receive those messages. This allows the asset tracker 102 and / or location services to find out the nearest gNB / UE / asset tracker in the vicinity of the asset tracker, which allows the asset tracker to change its configuration accordingly (e.g., transmit with less power to reduce the contact tracking range to at least include / reach one or more of the nearest gNB / UE / asset trackers in the vicinity of the asset tracker). In addition, if the location of one or more nearest gNB / UE / asset trackers is known (e.g., by GNSS or other means), the location of the asset tracker 102 can be estimated (e.g., by calculating the corresponding distance / angle between the asset tracker 102 and one or more nearest gNB / UE / asset trackers) by using this location information and / or the content of the message sent by the asset tracker 102 and / or measurements related to receiving the message sent by the asset tracker 102 (e.g., time of arrival, RSRP, angle of arrival). In an embodiment variant, message X can include configuration information that the asset tracker 102 should use to send message B (e.g., a transmit power indication or a time / frequency to be used).

[0328] In an embodiment variant, the network reconfigures the gNB / UE / asset tracker 601 based on the messages N and / or O it has received (e.g., by sending new policies / configurations to those gNB / UE / asset trackers), for example to adapt the response messages X and Y that those devices send to the asset tracker 102, or the criteria / conditions for when to send those messages.

[0329] In an embodiment variant, in the event that a signal carrying message A is not received by a gNB / UE / asset tracker 601 (_1…K) in range r1 and / or a signal carrying message B is not received by a gNB / UE / asset tracker 601 (_1…M) in range r2, the signals may be blocked by an obstacle. The location service or device performing the position estimation of the asset tracker 102 may detect this by determining an estimate of the distance r1 based on the message N it has received from one or more gNB / UE / asset trackers 601 (_1…K) (or message X in the case where the position is determined by the asset tracker 102 itself). Similarly, this may be done for range r2 based on the message O it has received from one or more gNB / UE / asset trackers 601 (_1…M) in range r2 (or message Y in the case where the position is determined by the asset tracker 102 itself). If a gNB / UE / asset tracker 601 is known to be in range r1 (respectively in r2), but the corresponding device has not yet sent message N, O, X, or Y, then the gNB / UE / asset tracker 601 may be marked. Additionally or alternatively, a gNB / UE / asset tracker 601 is known to be in range r1 (respectively in r2) and is preconfigured / requested to send a message indicating whether it has received message A or B, and if it sends a message that it has not received message A or B, then the gNB / UE / asset tracker 601 may be marked. The marked gNB / UE / asset tracker 601 may be preconfigured or requested (e.g., by location services) to send messages (e.g., PRS / SRS signals for distance measurement or ProSe discovery messages) to determine which devices (e.g., other gNB / UE / asset trackers or asset tracker 102) can receive those messages. In addition, such a tagged gNB / UE / asset tracker may be preconfigured or requested to listen for additional messages from the asset tracker 102 or other gNB / UE / asset trackers, whereby those devices may be requested to send one or more messages to the tagged gNB / UE / asset tracker. This information may be used by a location service or device performing location estimation to determine which devices (e.g., other gNB / UE / asset trackers or asset tracker 102) may receive these messages and thereby identify potential obstacles and / or which signals may be blocked and which signals may not be blocked. Additionally or alternatively, such a tagged gNB / UE / asset tracker 601 may be preconfigured or requested to perform wireless sensing of the environment to determine any potential nearby obstacles that may have prevented the reception of message A or message B.The resulting information about potential obstacles or signals being blocked may be used to determine whether the tagged gNB / UE / asset tracker 601 or its measurements should be excluded from calculations to perform a position estimate for the asset tracker 102, and / or may be used to determine that the UE / asset tracker 601 should not be the cluster leader. Additionally or alternatively, the resulting information may be used to reconfigure the asset tracker 102 and / or the tagged gNB / UE / asset tracker 601 to change certain transmission parameters (e.g., increase signal strength, redirect antennas, adapt signal modulation), and / or instruct / request the asset tracker 102 and / or the tagged gNB / UE / asset tracker 601 to relocate itself.

[0330] In other words, a system / method / apparatus for position estimation of a tracker 102 may be provided, wherein the tracker 102 may be configured / instructed to send a first message having a first set of signal transmission characteristics and a second message having a second set of signal transmission characteristics, wherein one or more signal transmission characteristics in the second set of signal transmission characteristics are different from the first set, and wherein the first message may be received by a first set of gNB / UE / asset trackers 601 (_1…K), and wherein the second message may be received by a second set of gNB / UE / asset trackers 601 (_1…M), wherein the position of the tracker 102 is determined in part based on the fact that one or more gNB / UE / asset trackers may be in the first set but not in the second set (or vice versa).

[0331] Additionally, a system / method / apparatus for reconfiguration of a tracker 102 may be provided, wherein the tracker 102 may be configured / instructed to send a first message having a first set of signal transmission characteristics and a second message having a second set of signal transmission characteristics, wherein one or more signal transmission characteristics in the second set of signal transmission characteristics are different from the first set, and wherein the first message may be received by a first set of gNB / UE / asset trackers 601 (_1…K), and wherein the second message may be received by a second set of gNB / UE / asset trackers 601 (_1…M), wherein a configuration of the tracker 102 (e.g., signal transmission characteristics or contact tracking range) is changed / determined in part based on the fact that one or more gNB / UE / asset trackers may be in the first set but not in the second set (or vice versa).

[0332] In an embodiment that may be implemented independently or in combination with other embodiments, the asset tracker 102 uses backscatter-based communication whereby the gNB / UE / asset tracker 601 transmits an illumination signal to the asset tracker 102 to enable the asset tracker 102 to create and transmit (i.e., in the case of backscatter communication by modulating the incoming illumination signal to reflect / transmit) messages A and B. Instead of the asset tracker 102 determining the signal characteristics of messages A and B, the gNB / UE / asset tracker 601(_X) transmits an illumination signal having different signal characteristics (e.g., different transmit power) for message A than for message B, and / or a different gNB / UE / asset tracker 601(_Y) is used to transmit an illumination signal for message B than the gNB / UE / asset tracker 601(_X) used to transmit the illumination signal for message A. The signal characteristics of message A may be determined according to a (preconfigured) policy or schedule / configuration (which may be provided to the respective devices by a location service such as an LMF), and / or may be determined according to an "estimated" or initial location of the asset tracker 102 (e.g., transmitting the illumination signal with sufficient transmit power to reach the asset tracker 102), and / or may be determined based on which gNB / UE / asset trackers 601 are close to the asset tracker 102 (e.g., transmitting with such signal strength and / or frequency and / or signal type that allows the reflected / transmitted modulated signal to be received by as many gNB / UE / asset trackers 601 as possible). The illumination signal may be sent in the direction where the asset tracker 102 is expected to be located. To this end, the gNB / UE / asset tracker 601 (_X) or location service may use an initial estimate of the asset tracker 102 so far (e.g., based on information from the application or provided via the NEF, or based on historical information, such as a previously known location of the asset tracker, e.g., based on earlier reported messages). The location service may select a gNB / UE / asset tracker 601(_X) at a location known / estimated to be closest to the estimated / initial location of the asset tracker 102 to send a first illumination signal to the asset tracker 102 to enable the asset tracker 102 to reflect / transmit a signal resulting from the modulated illumination signal, the modulated signal constituting message A. To this end, the location service (or gNB / UE / asset tracker) may send a message to the selected gNB / UE / asset tracker 601(_X), which may include a request to send the first illumination signal. Such a message may also include configuration information (e.g., signal characteristics to be used), the identity of the asset tracker 102, and / or angle / distance / position information associated with the asset tracker 102. The same gNB / UE / asset tracker 601(_X) may also be used to send a second illumination signal (with different signal characteristics) to the asset tracker 102 to enable the asset tracker 102 to send message B.Based on which gNB / UE / asset trackers 601(_1…K) received message A and / or measurements (e.g., signal strength, angle of arrival) made by the gNB / UE / asset tracker 601(_1…K) based on the received message A and / or distance / positioning estimates calculated by the asset tracker 102 based on message A and / or measurements related to receiving message A, different gNB / UE / asset trackers (_Y) may be used to send a second illumination signal (possibly with different signal characteristics) to the asset tracker 102. To this end, the location service (or gNB / UE / asset tracker) may send a message to the different gNB / UE / asset tracker 601(_Y), which message may include a request to send the second illumination signal. Such a message may also include configuration information (e.g., signal characteristics to be used), the identity of the asset tracker 102, and / or angle / distance / position information related to the asset tracker 102. The signal characteristics of message B may be determined based on a (preconfigured) policy or schedule / configuration (which may be provided to the corresponding device by a location service such as LMF) and / or may be based on which gNB / UE / asset trackers 601(_1…K) have already received message A (i.e., as reported in message N) and / or an initial position estimate of the asset tracker 102 (e.g., based on message A being received by one or more gNB / UE / asset trackers). As a further option, the asset tracker 102 measures the arrival time and / or signal strength of the received lighting signal, and may include a value related to the arrival time of the received lighting signal and / or a value related to the departure time of the reflected / transmitted signal, and / or a signal processing delay (e.g., in microseconds) and / or a measure of the signal strength of the received lighting signal (e.g., RSRP) and / or an indication of antenna loss of an antenna of the asset tracker 102 (e.g., in dBm, which may have a different received value than the reflected / transmitted value), and / or include a transmit power (or other energy indicator) of the modulated signal reflected / transmitted by the asset tracker 102 in a message (e.g., message B) that may be received by one or more nearby gNB / UE / asset trackers 601 (_1…M) and may be further propagated to the network. The gNB / UE / asset tracker 601 receiving the reflected / transmitted modulated signal may use the arrival time of the incident illumination signal at the asset tracker 102 and / or the departure time of the reflected / transmitted modulated signal (e.g., constituting message B) and / or the difference between the arrival time and the departure time and / or the signal processing delay of the asset tracker 102 together with other measurements (e.g., time of arrival, angle of arrival of the received modulated signal) to calculate one or more distances, angles between the asset tracker 102 and these gNB / UE / asset trackers and / or calculate / estimate the positioning of the asset tracker 102.Similarly, the gNB / UE / asset tracker 601 receiving the reflected / transmitted modulated signal may use the signal strength of the received illumination signal and / or the transmit power (or other energy indicator) of the reflected / transmitted modulated signal and / or antenna loss information with other measurements, such as the signal strength in the received modulated signal (e.g., RSRP), to calculate one or more distances, angles, and / or calculate / estimate the location of the asset tracker 102 between the asset tracker 102 and these gNB / UE / asset trackers. Similar to other embodiments, message A may be received by a first set of gNB / UE / asset trackers 601 (_1...K) in range r1, and message B may be received by a second set of gNB / UE / asset trackers 601 (_1...M) in range r2. The fact that message A is received by the gNB / UE / asset trackers in the first set but not by the gNB / UE / resource trackers in the second set may be used by the asset tracker or location service to include / exclude areas where the asset tracker 102 may reside.

[0333] In an embodiment variant, in the event that a signal carrying message A is not received by a gNB / UE / asset tracker 601 (_1…K) in range r1 and / or a signal carrying message B is not received by a gNB / UE / asset tracker 601 (_1…M) in range r2, the signals may be blocked by an obstacle. The location service or device performing the position estimation of the asset tracker 102 may detect this by determining an estimate for range r1 based on message N (or message X in the case where the position is determined by the asset tracker 102 itself) that it has received from one or more gNB / UE / asset trackers 601 (_1…K). Similarly, this may be done for range r2 based on message O (or message Y in the case where the position is determined by the asset tracker 102 itself) that it has received from one or more gNB / UE / asset trackers 601 (_1…M) in range r2. If a gNB / UE / asset tracker 601 is known to be in range r1 (respectively in r2), but the corresponding device has not yet sent message N, O, X or Y, then the gNB / UE / asset tracker 601 may be marked. Additionally or alternatively, a gNB / UE / asset tracker 601 is known to be in range r1 (respectively in r2) and is preconfigured / requested to send a message indicating whether it has received message A or B, and if it sends a message that it has not received message A or B, then the gNB / UE / asset tracker 601 may be marked. In the case of using backscatter communication, the tagged gNB / UE / asset tracker may be requested to send an illumination signal to the asset tracker 102 and determine whether it receives a reflected / transmitted modulated signal (e.g., carrying message A or B), after which the tagged gNB / UE / asset tracker may report it to a location service or device performing a position estimation of the asset tracker 102. Similarly, other gNB / UE / asset trackers 601 in the vicinity may report whether they receive reflected / transmitted modulated signals based on the illumination signal from the tagged gNB / UE / asset tracker. This information may be used by a location service or device performing position estimation to determine which devices (e.g., other gNB / UE / asset trackers or asset tracker 102) may receive these messages and, therefore, identify potential obstacles and / or which signals may be blocked and which signals may not be blocked. The resulting information about potential obstacles or signals that are blocked may be used to determine whether the tagged gNB / UE / asset tracker 601 or its measurements should be excluded from calculations to perform position estimation for the asset tracker 102, and / or may be used to determine that the UE / asset tracker 601 should not be the cluster leader.Additionally or alternatively, the resulting information may be used to reconfigure the asset tracker 102 and / or the tagged gNB / UE / asset tracker 601 to change certain transmission parameters (e.g., increase signal strength, redirect antennas, adapt signal modulation), and / or instruct / request the asset tracker 102 and / or the tagged gNB / UE / asset tracker 601 to relocate itself.

[0334] In other words, a system / method / apparatus for position estimation of a tracker 102 may be provided, wherein the tracker 102 may be adapted to receive a first illumination signal (i.e., from a first gNB / UE / asset tracker 601) so as to be able to send / transmit a first message having a first set of signal transmission characteristics and receive a second illumination signal (i.e., from a second gNB / UE / asset tracker 601, which may be the same as the first gNB / UE / asset tracker 601) so as to be able to send / transmit a second message having a second set of transmission characteristics, wherein one or more of the signal transmission characteristics in the second set of transmission characteristics are different from the first set, and wherein the first message may be transmitted by the first gNB / UE / asset tracker 601. The first message may be received by a set of gNB / UE / asset trackers 601 (_1…K), and wherein the second message may be received by a second set of gNB / UE / asset trackers 601 (_1…M), wherein the location of the tracker 102 is determined based on which gNB / UE / asset trackers 601 (_1…K) received the first message and / or which gNB / UE / asset trackers 601 (_1…M) received the second message, and / or based on measurements performed by the first set and / or the second set of gNB / UE / asset trackers based on receiving the first message and the second message, respectively, and / or based on the fact that one or more gNB / UE / asset trackers may be in the first set but not in the second set (or vice versa).

[0335] The second set of transmission characteristics may be configured / indicated to be different from the first set of transmission characteristics based on which gNB / UE / asset trackers 601(_1…K) receive the first message and / or based on measurements performed by the gNB / UE / asset tracker 601(_1…K) based on receiving the first message and / or based on a distance / position estimate of the asset tracker 102 calculated based on the first message.

[0336] The system / method / apparatus may also be adapted to select a second gNB / UE / asset tracker 601 different from the first gNB / UE / asset tracker 601, and / or cause the second gNB / UE / asset tracker 601 to send the second lighting signal using a set of signal transmission characteristics different from the set of signal transmission characteristics used to send the first lighting signal, thereby selecting / adapting the set of signal transmission characteristics for the second gNB / UE / asset tracker 601 and / or the second lighting signal based on which gNB / UE / asset trackers 601 (_1…K) receive the first message and / or based on measurements performed by the gNB / UE / asset tracker 601 (_1…K) based on receiving the first message and / or based on a distance / position estimate of the asset tracker 102 calculated based on the first message.

[0337] Additionally, a system / method / apparatus for reconfiguring a tracker 102 may be provided, wherein the tracker 102 may be adapted to receive a first illumination signal so as to be able to send / transmit a first message having a first set of signal transmission characteristics, and adapted to receive a second illumination signal so as to be able to send / transmit a second message having a second set of transmission characteristics, wherein one or more signal transmission characteristics in the second set of transmission characteristics are different from the first set, and wherein the first message may be received by a first set of gNB / UE / asset trackers 601 (_1…K), and wherein the second message may be received by a second set of gNB / UE / asset trackers 601 (_1…M), wherein a configuration of the tracker 102 (e.g., signal transmission characteristics or contact tracking range) is changed / determined in part based on the fact that one or more gNB / UE / asset trackers may be in the first set but not in the second set (or vice versa).

[0338] In summary, asset tracking systems and methods have been described that allow telecommunication or other wireless networks to track low-capability, low-cost asset trackers while significantly reducing the power requirements of the asset trackers by providing mutual contact tracking over a low-power local protocol by the trackers. Contacts may be reported to the network, which is able to optimize the tracker's power usage with its ongoing model's position certainty by reducing the number and / or transmission power of uplink or D2D transmissions, and / or through fixed or dynamic cluster formation as needed.

[0339] Although the present invention has been illustrated and described in detail in the accompanying drawings and the foregoing description, such illustration and description are to be considered illustrative or exemplary rather than restrictive. The present invention is not limited to the disclosed embodiments. The proposed enhanced asset tracking system and process can be implemented in all types of wireless networks, for example, it can be applied to trackers that communicate using cellular wireless communication standards, particularly the Third Generation Partnership Project (3GPP) 5G and New Radio (NR) specifications. The 5G wireless communication tracker can be different types of devices, such as mobile phones, smart watches, smart tags for location tracking and logistics, vehicles (for vehicle-to-vehicle (V2V) communication or more generally vehicle-to-everything (V2X) communication), V2X devices, IoT hubs, IoT devices, including low-power medical sensors for health monitoring, medical (emergency) diagnostic and treatment equipment, for hospital use or first responder use, virtual reality (VR) headsets, etc.

[0340] Although ProSe relay and sidelink communication have been described, the present invention is also applicable to other types of relay devices, such as (smart) repeater devices, (cellular) gateway UEs, integrated access and backhaul (IAB) nodes, or Wi-Fi mesh APs, or other types of intermediate nodes capable of forwarding corresponding messages (e.g., contact reports) received from tracker devices.

[0341] In addition, the present invention can be applied to medical applications or connected healthcare where multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes are involved in medical applications or connected healthcare where wireless (e.g., 4G / 5G) connected devices occasionally consume or generate continuous data streams of a certain average data rate, such as video, ultrasound, X-ray, computed tomography (CT) imaging equipment, real-time patient sensors, audio or voice or video streaming devices used by medical personnel, IoT applications generally involving wireless, mobile or fixed sensor or actuator nodes (e.g., smart cities, logistics, agriculture, etc.), emergency services and critical communications applications, V2X systems, systems for improved coverage of 5G cellular networks using high-frequency (e.g., millimeter wave) RF, and any other application areas of 5G communications using relays.

[0342] Other variations to the disclosed embodiments may be understood and implemented by those skilled in the art in practicing the claimed invention by studying the drawings, the disclosure, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. The foregoing description details certain embodiments of the invention. However, it should be understood that, regardless of the details presented herein in the foregoing, the invention may be practiced in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of a particular term in describing certain features or aspects of the invention should not be taken as implying that the term is redefined herein to be limited to including any particular characteristics of the features or aspects of the invention associated with the term.

[0343] Furthermore, in those cases where a convention similar to "at least one of A, B, and C, etc." is used, generally such construction is intended to be in the sense that a person skilled in the art would understand the convention, for example, "a system having at least one of A, B, and C" would include but is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. In those cases where a convention similar to "at least one of A, B, or C, etc." is used, generally such construction is intended to be in the sense that a person skilled in the art would understand the convention, for example, "a system having at least one of A, B, or C" would include but is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, and C together, etc. A person skilled in the art would further understand that any disjunctive words and / or phrases that actually present two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase "A or B" would be understood to include the possibility of "A" or "B" or "A and B."

[0344] A single unit or device may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.

[0345] The operations described (such as Figures 2 to 4 The operations indicated in the description) can be implemented as program code means of a computer program and / or dedicated hardware of a debugging device or a lighting device, respectively. The computer program can be stored and / or distributed on a suitable medium (such as an optical storage medium or a solid-state medium) provided together with or as part of other hardware, but can also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

1. An apparatus for controlling a tracker (102, 104, 1066) to provide information about the tracker (102, 104, 1066) and / or a tracked item to a tracker control system via a wireless network (20), wherein: The device is suitable for: Perform local contact tracing of other tracers (102, 104, 1066); as well as A contact report derived from the local contact tracking is provided to the tracker control system.

2. The device according to claim 1, wherein: The contact report includes the contacted tracker identity and / or the contacted tracker type and / or the contacted tracker sensing value and / or the contacted tracker location and / or the contacted tracker location information.

3. The device according to claim 1 or 2, wherein: The local contact tracking is configured to save energy of the trackers (102, 104, 1066) of the tracker control system by at least one of: combining individual contact reports to reduce the number and range of uplink communications required by any of the trackers (102, 104, 1066), allowing network or cluster controlled sleep and / or wake cycles of the trackers (102, 104, 1066), and delegating the task of maintaining network contact to the trackers (102, 104, 1066).

4. The device according to claim 3, wherein: The apparatus is adapted to maintain functionality even when out of coverage of the wireless network (20) by enabling the tracker (102, 104, 1066) to be locally provisioned and maintained in such a way that the tracker (102, 104, 1066) is discoverable at appropriate times and reports information about contact with the tracker (102, 104, 1066) while out of coverage.

5. A device according to any one of the preceding claims, wherein: The apparatus is adapted to control a contact tracking range (52, 54) and / or a sleep and / or wake cycle of the tracker (102, 104, 1066) based on at least one of a position and a detected movement of the tracker (102, 104, 1066).

6. A device according to any one of the preceding claims, wherein: The device is adapted to enter a provisioning mode in which the device attempts to discover the wireless network (20) and / or a local tracker (1066) that is part of a cluster (106).

7. An apparatus for controlling a tracker control system operating via a wireless network (20), wherein: The device is suitable for: obtaining information about a plurality of trackers (102, 104, 1066) of the tracker control system and / or tracked items, the information being reported by at least one tracker of the plurality of trackers (102, 104, 1066) via contact tracking; as well as At least one of the plurality of trackers (102, 104, 1066) is controlled to change at least one of a contact tracking range (52, 54) and a sleep and / or wake-up cycle and / or reduce the number of uplink transmissions and / or form a cluster (106) of trackers (1066).

8. The device according to claim 7, wherein: The apparatus includes a network-side model (202) configured to change at least one of the contact tracking ranges (52, 54) and the sleep and / or wake cycles of the plurality of trackers (102, 104, 1066).

9. The device according to claim 8, wherein: The network-side model (202) is adapted to calculate known or inferred location-related information for each of the plurality of trackers (102, 104, 1066) using received identification information reported by the plurality of trackers (102, 104, 1066) and known location-related information of some of the plurality of trackers (102, 104, 1066) and / or non-tracker devices.

10. The device according to claim 7, 8 or 9, wherein: The apparatus is adapted to enable provisioning of at least one cluster (106) of trackers (1066) in a manner such that the cluster (106) is discoverable by a tracker (104) or the tracker control system and is configured to report information about tracked contacts with a tracker (1066) of the cluster (106) when out of coverage of the wireless network (20).

11. A tracker (102, 104, 1066) comprising the device according to any one of claims 1 to 6.

12. The tracker according to claim 11, wherein: The tracker (102, 104, 1066) is adapted to provide location information to a tracker control system, and wherein the contact report includes information regarding contact with another tracker (102, 104, 1066).

13. A tracker control system comprising a plurality of trackers (102, 104, 1066) according to claim 11 or 12 and a wireless network (20), the wireless network (20) comprising an apparatus according to any one of claims 7 to 10 in a network device and / or in a cluster head (1062) of a cluster (106) of cluster trackers (1066), wherein: The system also includes a synchronization device (1064) for providing a time synchronization reference signal to the cluster trackers (1066) within the cluster.

14. A method of controlling a tracker (102, 104, 1066) to provide information about the tracker (102, 104, 1066) and / or a tracked item to a tracker control system via a wireless network (20), wherein: The method comprises: performing local contact tracing of other tracers (102, 104, 1066); and A contact report derived from the local contact tracking is provided to the tracker control system.

15. A method of controlling a tracker control system operating via a wireless network (20), wherein: The method comprises: obtaining information about a plurality of trackers (102, 104, 1066) and / or tracked items of the tracker control system, the information being reported by at least one tracker of the plurality of trackers (102, 104, 1066) via contact tracking; and At least one of the plurality of trackers (102, 104, 1066) is controlled to change at least one of a contact tracking range (52, 54) and a sleep and / or wake-up cycle and / or reduce the number of uplink transmissions and / or form a cluster (106) of trackers (1066).

Images