Contact Tracing for Trackers of Low-Power Assets

Abstract

The present invention relates to an asset tracking system and method that enables trackers of low-capability and low-cost assets to be tracked by an electrical communication network or other wireless network while significantly reducing the power demand of the asset trackers by providing mutual contact tracing by the trackers via a low-power local communication protocol. Contacts are reported to the network, and the network can optimize the power usage by the trackers for the location certainty of the tracker location estimates stored in its current model by reducing the number and / or their transmission power of uplink transmissions or D2D transmissions, and / or by fixed cluster formation or dynamic cluster formation as required.

Description

Technical Field

[0001] The present invention relates to a tracker control system used, for example, for contact tracing, asset tracking, etc. in a wireless network such as a cellular network, particularly a fifth-generation (5G) or higher-generation cellular network, without limitation.

Background Art

[0002] Driven by public health and other use cases, contact tracing (identifying other devices whose devices are observed within a certain range) has increased rapidly in recent years. "An Empirical Assessment of Global COVID-19 Contact Tracing Applications" by Ruoxi Sun et al., aRxiv:2006.10933v6 [cs.CR] January 22, 2021, describes that the problem of contact tracing is that the central authority executes a linkage attack, thereby discovering the user's location history from the interaction with other users. "CAUDHT: Decentralized Contact Tracing Using a DHT and Blind Signatures" by Samuel Brack et al., IEEE 2020, discloses options for defending against such attacks. The possibility of a linkage attack in contact tracing is regarded as a problem in the field of public health, but contact tracing is used to provide a desired function in the use case of asset tracking.

[0003] Asset tracking utilizes sensors and / or connected devices to enable remote monitoring and management of an asset's geographical location (geolocation) and / or movement. Some manufacturers of Bluetooth-based asset trackers have added contact tracing as an additional feature to their products (e.g., Bluetooth Low Energy (BLE) tags for indoor asset tracking that can be worn by people or attached to important devices, along with real-time and historical contact tracing). Real-time contact tracing enables organizations to implement social distancing measures by monitoring the number of people present in a specific area and establishing proactive density control. However, the contact tracing function and tag tracking function are not integrated in such products.

[0004] In addition, asset tracking is a use case for future telecommunications networks. The first use case was defined for asset trackers in the 3GPP (registered trademark) specification R17 TR 22.836, but tracking objects smaller than the size of a pallet was not considered.

[0005] Among several advancements, cost reduction of chipsets has significantly reduced the cost of asset trackers for narrowband IoT (NB-IoT) systems and machine long-term evolution (LTE-M) systems, which means that many more assets will be tracked in the future. One example is printable NB-IoT-based tracking labels for monitoring its products through the supply chain. This smart label incorporates a cellular subscriber identification module (iSIM) function, along with several sensors, a printable battery, a microprocessor, an antenna, and a modem, into a communication module as a layout on printable silicone. This connects to the cellular network after being peeled off or cut off after printing and attachment to the package.

[0006] As confirmed in ranging studies by Mario H. Castaneda Garcia et al.'s "A Tutorial on 5G NR V2X Communications" in the IEEE Communications Surveys & Tutorials journal (DOI 10.1109 / COMST.2021.3057017) and by Zoraze Ali et al.'s "3GPP (R) NR V2X Mode 2: Overview, Models and System-Level Evaluation" in IEEE Access on June 29, 2021 (DOI: 10.1109 / ACCESS.2021.3090855), existing device-to-device (D2D) communication techniques enable a form of contact tracing (either within or outside coverage), but usually require overly frequent communication and furthermore do not provide network-side assets as an easy means to modify the contact tracing functionality performed by devices on the D2D link. Therefore, the requirements for an asset tracking system include a long battery life or generally low power consumption of the asset tracker and require a power-saving mode of communication.

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

Summary of the Invention

Problems to be Solved by the Invention

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

Means for Solving the Problems

[0009] This object is achieved by the device claimed in claims 1 and 7, by the tracker claimed in claim 11, by the tracker control system claimed in claim 13, by the methods claimed in claims 14 and 15, and by the computer program product.

[0010] According to a first aspect, there is provided an apparatus (e.g., in a tracker) for controlling a tracker to provide information about an item (article) to be tracked and / or a tracker to a tracker control system via a wireless network, the apparatus being performing local contact tracing of other trackers, and providing a contact report derived from the local contact tracing to the tracker control system and being adapted to.

[0011] According to a second aspect, there is provided an apparatus (e.g., in an access device of a wireless network, in a core network function of a core network of a wireless network, or in a tracker having the role of a cluster head of a cluster of trackers) for controlling a tracker control system operating via a wireless network, the apparatus being acquiring information about items to be tracked by the tracker control system and / or a plurality of trackers, the information being reported by at least one of the plurality of trackers via contact tracing, controlling at least one of the plurality of trackers to change at least one of a contact tracing range and a sleep and / or wake cycle and / or to reduce the number of uplink transmissions and / or to form a cluster of trackers and being adapted to perform. This change may be made, for example, to control a trade-off between the location estimation accuracy and the energy consumption of the plurality of trackers.

[0012] According to a third aspect, when the device of the first aspect or the tracker operates as a cluster head, a tracker including the device of the second aspect is provided.

[0013] According to a fourth aspect, a tracker control system is provided that includes a plurality of trackers according to the third aspect and a wireless network including a device according to the second aspect within a network device and / or within a cluster head of a cluster of cluster trackers.

[0014] According to a fifth aspect, a method of controlling a tracker to provide information about an item and / or a tracker to be tracked to a tracker control system via a wireless network is provided, the method comprising: performing local contact tracing of other trackers; providing a contact report derived from the local contact tracing to the tracker control system; and.

[0015] According to a sixth aspect, a method of controlling a tracker control system operating via a wireless network is provided, the method comprising: obtaining information about an item to be tracked by the tracker control system and / or a plurality of trackers, the information being reported by at least one of the plurality of trackers via contact tracing; controlling at least one of the plurality of trackers to change at least one of a contact tracing range and a sleep and / or wake cycle and / or to reduce the number of uplink transmissions and / or to form a cluster of trackers; and. This change may be made, for example, to control the trade-off between the location estimation accuracy and the energy consumption of the plurality of trackers.

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

[0017] Thus, a low-capability and low-cost (asset) tracker can be tracked by an electric communication network or other wireless network by mutual contact tracing by the tracker via a low-power local protocol, while significantly reducing the power demand of the asset tracker. By reducing the number of uplink transmissions or D2D transmissions and / or their transmission power, and / or by fixed cluster formation or dynamic cluster formation as required, contact can be reported to the network in order to provide optimization of the power usage by the tracker for the location certainty of the current model. The contact report is a message sent by the tracker and includes information related to the tracker, the tracker type, the value detected by the tracker, or the tracker location. In a specific example, the contact report includes information about contact with another tracker. This includes the identification information of the contacted tracker, the type of the contacted tracker, the value detected by the contacted tracker, the location of the contacted tracker, and / or the location information of the contacted tracker.

[0018] Thereby, the power demand of the tracker of the asset tracking system can be reduced under the control of the network-side model while maintaining a desired level of location accuracy by reducing the number of required uplink transmissions and / or D2D transmissions and / or reducing the relative time consumed by the tracker in the wake mode for the sleep mode.

[0019] Location-related information is location information (e.g., geographical coordinates or distance), other location-related information such as the presence of other trackers, or the signal strength (or other properties) of signals received from other trackers. In that case, the location system creates an estimate of the tracker location and uses this other location-related information to obtain the identifier of the item (to which the tracker is attached), the type of the item (to which the tracker is attached) and / or the detected value of the item (to which the tracker is attached) (e.g., temperature).

[0020] Furthermore, local contact tracing enables the formation of persistent clusters that can be together even when the trackers of the assets are outside network coverage. This enables local search for contacts while the trackers are outside coverage (the trackers are geographically mobile) and use these contacts to enable the network to maintain knowledge about the location of the trackers. The network also uses such mobile trackers to search for out-of-coverage clusters.

[0021] According to a first option that can be combined with any of the first to seventh aspects described above, local contact tracing is configured to save the energy of the trackers of the tracker control system by at least one of combining individual contact reports to reduce the number and range of uplink communications required for any of the trackers, enabling network-controlled or cluster-controlled sleep and / or wake cycles of the trackers, and delegating the task of maintaining network contacts to a tracker (e.g., a tracker that is predicted to have a longer operating life than other trackers in its vicinity). Thereby, contact tracing can be configured to optimize communication scheduling and the active periods of the trackers to reduce the energy consumption of the trackers.

[0022] According to a second option that can be combined with the first option or any one of the first to seventh aspects described above, the function of the tracker can be made discoverable at an appropriate time, and by enabling the tracker to be locally provisioned and maintained in such a way as to report information about contacts that occurred with the tracker while it was out of coverage, it is retained even when outside the coverage of the wireless network. Thereby, stand-alone trackers and isolated trackers can be detected and reintegrated into the network or cluster to optimize communication efficiency and energy consumption.

[0023] According to a third option that can be combined with the first option or the second option or any one of the first to seventh aspects described above, the contact tracing range and / or the sleep and / or wake cycles of the tracker are controlled based on at least one of the location of the tracker and the detected movement. Thus, individual trackers are enabled to reduce energy consumption by adapting their operating parameters to their location and movement state.

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

[0025] According to a fifth option that can be combined with any one of the first to fourth options or any one of the first to seventh aspects described above, a network-side model is provided and configured to control a trade-off by changing at least one of the contact tracing ranges of a plurality of trackers and the sleep and / or wake cycles. Accordingly, the wireless network can be configured to control the trade-off between the location estimation accuracy and the energy consumption of the tracker control system.

[0026] According to a sixth option that 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 is adapted to use the received identification information reported by a plurality of trackers and the known location-related information of some of the plurality of trackers and / or non-tracker devices to calculate the known or estimated location-related information of each of the plurality of trackers. Thereby, even when some trackers are out of coverage, the location estimates of all trackers in the tracker control system can be continuously provided through contact tracing.

[0027] According to a seventh option that can be combined with any one of the first to sixth options or any one of the first to seventh aspects described above, a provisioning of at least one cluster of trackers is enabled in such a way that the cluster is discoverable by the tracker or the tracker control system and is configured to report information about the traced contacts that occurred between the trackers of the cluster while outside the coverage of the wireless network. Thereby, even when some trackers in the cluster are out of coverage, the location estimates of all trackers in the tracker control system can be continuously provided through contact tracing within the cluster.

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

[0029] It should be noted that the above-described apparatus is implemented based on a configuration of individual hardware components, such as an individual hardware circuit, an integrated chip, or a chip module, or based on a signal processing device or chip controlled by software routines or programs stored in a memory, written on a computer-readable medium, or downloaded from a network such as the Internet.

[0030] It should be understood that the apparatus 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 have similar and / or identical preferred embodiments, particularly as defined in the dependent claims.

[0031] It should be understood that the preferred embodiments of the present invention can also be dependent claims with each independent claim or any combination of the above-described embodiments.

[0032] These and other aspects of the present invention will become apparent from and will be elucidated with reference to the embodiments described hereinafter.

Brief Description of the Drawings

[0033]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Embodiments for Carrying Out the Invention

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

[0035] Asset tracking is intended to refer to a method of tracking physical assets either by scanning barcode labels attached to the assets or by using tags that use, for example, the Global Positioning System (GPS), BLE, Long Range (LoRa), Radio Frequency Identification (RFID), WiFi, or DECT 2020 to broadcast their locations. These technologies can also be used for indoor tracking of people wearing tags.

[0036] An asset tracker (which may be referred to as a "tracker" in this disclosure) should be understood as a device (e.g., a tag, a sensor, etc.) that enables remote monitoring and / or management of the geographical location and / or movement of an item or asset.

[0037] Asset tracking can be used, for example, · to record (identification information of) an item located in a particular known location (e.g., within a container), · to identify which type of item is in a particular location, · to identify characteristics of an item (or environment) to which the tracker is attached (where the tracker is deployed) (e.g., a particular sensor output such as the temperature of a temperature sensor), or · to search for the location of the tracker and thus the item to which the tracker is attached. It can be used for this purpose.

[0038] The tracker can be attached to the item for which it should record (or deployed in a given area). In this disclosure, an asset tracker is regarded as a particular class of user equipment device (UE) that implements a subset of 3GPP (registered trademark) specifications.

[0039] Throughout this disclosure, the term "wireless network" is intended to mean an entire network system (e.g., a 4G or 5G system) that includes communication devices (e.g., UEs), a radio access network (RAN), and optionally a core network (CN). Further, the abbreviations "eNB" (a 4G term) and "gNB" (a 5G term) are intended to mean access devices such as cellular base stations, WiFi access points, or UWB PAN coordinators. The eNB / gNB is part of the RAN that is capable of providing an interface to functions within the CN. The RAN is part of a wireless communication network. The RAN implements a radio access technology (RAT). Conceptually, the RAN exists between communication devices such as mobile phones, computers, or any remotely controlled machine, and provides a connection to its CN. The CN is the core part of a communication network that provides a number of services to customers interconnected via the RAN. More specifically, the CN directs communication streams, possibly via other networks, through the communication network. Among other things, the 3GPP (registered trademark) specifications 23.303, 23.304, 24.334, and 24.554 for 4G networks and 5G networks respectively define a so-called proximity service (ProSe) function to enable the connectivity of cellular communication devices (e.g., UEs) that are temporarily out of the coverage of an access device (eNB). This particular function is called ProSe UE-network relay or relay UE. The relay UE is a communication device that helps an out-of-coverage (OoC) UE communicate with the eNB (i.e., the access device) by relaying application and network data traffic in both directions between another OoC UE and the eNB. The local communication between the relay UE and the OoC-UE is called D2D communication, sidelink communication, or PC5 communication. The abbreviation "PC5" refers to the interface for sidelink communication defined by ProSe.Furthermore, the abbreviation "UL" is used in the uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used in the downlink direction from an access device (e.g., eNB, gNB) to a communication device (e.g., UE), and the abbreviation "SL" is used for sidelink / D2D communication between two or more communication devices (e.g., UE).

[0040] When the relay relationship is established, the OoC-UE is connected via the relay UE and acts as a "remote UE". This situation means that, in contrast to the direct network connection in the normal case, the remote UE has an indirect network connection to the CN (see 3GPP (registered trademark) specification TS 22.261 v16.10.0).

[0041] Furthermore, 3GPP (registered trademark) specifications TR 23.733 v15.1.0 and TR 36.746 v15.1.1 are conducting research on architecture enhancements to enable IoT devices (acting as remote UEs) to operate with ultra-low power, for example, by using a relay UE to connect to a wider network. Since the relay UE is physically very close, it is possible to reach the relay UE using ultra-low power transmission. This research also includes improvements in ProSe security, speed, and stability. These extensions of ProSe are called Extended ProSe ("eProSe").

[0042] ProSe can also be used for direct communication between two UEs. Further radio-level details regarding ProSe, V2X, and sidelink communication can be found in 3GPP (registered trademark) specifications TR 37.985, TS 38.300, and TR 38.836.

[0043] Ranging can be defined as the process of measuring the distance and / or relative orientation angle between two wireless devices in a 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 from the other UE. These ranging-based services are assumed to be supported with or without network coverage. Following the measurement of distance and orientation angle, a relevant measurement is whether the two wireless devices are in direct line of sight, because this is relevant to many use cases where UEs are considered to interact with each other when they are in line of sight, for example, in the same room.

[0044] The so-called ranging reference signal is used to determine the distance and / or angle between two devices connected through a D2D connection (e.g., using sidelink and / or PC5) rather than an infrastructure connection (e.g., using the Uu interface). The ranging reference signal is a positioning reference signal and / or a sounding reference signal or other signals (e.g., signals used for round-trip time (RTT) measurement), and these signals use, in some cases, resources for device-to-device (e.g., sidelink) communication (configured or permitted by the access device) and / or resources specifically reserved for sending the reference signal or other signals used to determine the distance and / or angle between devices to determine the distance and / or angle between devices.

[0045] Since multiple antennas are required, not all devices are capable of calculating angles. The ranging capabilities of the device (which may be exchanged as part of the discovery process) can be used to determine what the device can do and what measurements can be made. Note that angle calculation requires an explicit ability, not just based on the ability to state the number of antennas. Just because the number of antennas is greater than one does not automatically mean that the device is capable of calculating angles. Angle calculation further requires sensors (e.g., magnetometer, gyroscope, accelerometer) for deriving orientation and / or angles towards a reference point such as magnetic north, and an angle / orientation calibration mechanism. Angles can also be determined by indicating the difference in altitude, using a reference altitude (e.g., meters above sea level and / or air pressure, floor information, terrain altitude data of the device's location), and an altitude calibration mechanism.

[0046] For example, the ranging measurements between two UEs described in the ranging study "A Tutorial on 5G NR V2X Communications" by Mario H. Castaneda Garcia et al. (DOI 10.1109 / COMST.2021.3057017) yield two parameters: the distance between the two UEs in meters and the angle in degrees at which the target UE rises from the observer UE in a 3D plane.

[0047] Furthermore, so-called "peer-to-peer ranging" can be performed in many ways, including but not limited to the following. i. Two-way ranging, which is a process in which two devices A and B communicate data packets and acknowledgment packets that travel back and forth between them. In this technique, the time delays caused by natural wireless signal propagation and the processing delay at device B (i.e., the time it takes for device B to retransmit a packet to device A) are considered. Then, the one-way time of flight is calculated on device A as half of the difference between a) the time spent between device A transmitting a packet and receiving the next packet from B, and b) the time spent between device B receiving a packet from A and transmitting and sending back an acknowledgment packet to A. Device B includes information in its acknowledgment packet so that A can calculate the time B spends. Then, at device A, the one-way time of flight is used to calculate the distance between the two devices A and B. Device B performs the same procedure as device A so that B can also calculate this distance. Since the processing delay is considered in two consecutive packet transmissions and the distance is calculated simultaneously at both devices, the clocks of the two devices do not need to be synchronized with each other in this technique. ii. One-way ranging, which is a process in which at least one packet is transmitted between a transmitting wireless device A and a receiving wireless device B. These devices are synchronized with each other by a common clock source. Then, the time of flight is measured as the difference between the time of reception at device B and the time of transmission at device A. Device A includes the time stamp of its transmission time in the data packet so that device B can calculate this time difference. The accuracy of ranging depends on the accuracy of clock synchronization achievable between the two devices.

[0048] The peer-to-peer ranging operation depends on multiple parameters of wireless communication, such as clock time synchronization between devices, the communication path through which the signal is transmitted (e.g., line-of-sight (LOS) or non-line-of-sight (NLOS)), the nature of the antenna, the operating frequency, the transmission power of the wireless radio, and the receiver sensitivity. These parameters are also important for wireless communication in general, and as a result, a number of standardized techniques have been developed to achieve the highest communication performance of a given radio. For example, in 3GPP (registered trademark), the sidelink radio resource protocol described in specification 36.331 v16.4.1 guarantees high-precision clock time synchronization between two sidelink UEs operating in multiple in-coverage scenarios and out-of-coverage scenarios.

[0049] Positioning can be defined as a process of determining the location coordinates of wireless devices such as mobile phones, wearables, and IoT devices, although not limited to, according to a location coordinate system. Once the location coordinates of a device are determined, the device can be placed on a map using a mapping function. Positioning is typically distinguished between absolute positioning (i.e., determining geographical coordinates (location coordinates) according to a standardized geographical coordinate system) and relative positioning (i.e., determining coordinates (e.g., using a local coordinate system) and / or angles and distances relative to a reference point). Some examples of how absolute or relative positions can be represented can be found in the 3GPP (registered trademark) specification TS 23.032. A typical example is satellite-based location services (e.g., Global Positioning System (GPS) or Global Navigation Satellite System (GNSS)), where the location coordinates of a device are calculated using well-known processes such as triangulation and trilateration, using at least three of many satellites belonging to a constellation of medium Earth orbit (MEO) satellites. The satellites act as clock synchronization sources, and the communication delay of the transmitted packets is used to estimate the location coordinates. These coordinates can be used by any third-party mapping tool (e.g., OpenStreetMap) to accurately indicate the location of the device on a geographical map of the area. Also, several indoor positioning techniques based on radio frequency technologies such as Bluetooth, UltraWideBand (UWB), or Wi-Fi are available, which can locate / determine the coordinates of radio frequency (RF) emission tags within an indoor environment. The positions of these tags are then mapped on an indoor floor plan using indoor coordinates estimated based on RF propagation properties such as time delay, multipath reflection, and received signal strength measured using RF communication between the tag and anchor nodes placed at pre-known locations in the building. In the example, signal strength is directly used to estimate a single range or to estimate multiple ranges and positions at once using multiple collected measurements for better performance.

[0050] The positioning techniques used to obtain the coordinates of the current location of a device can be implemented in several ways, but usually involve 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. The distances and angles can be determined using various techniques including round-trip time (RTT), time of flight (ToF), time difference of arrival (TDoA), angle of arrival / departure (AoA / AoD), and / or combinations thereof.

[0051] The round-trip time (RTT) defines the duration from when a data packet is transmitted by a transmitter (Tx, e.g., an access point / device) until the same data packet is received by a receiver (Rx, e.g., a mobile phone / device) and an affirmative response is sent, i.e., until the moment the transmitter receives the affirmative response. Since data packets move through the air medium at the speed of light (approximately 3.3 ns / m), the duration for which the data packet travels through the air is proportional to the actual distance between the Tx and the Rx. In scenarios where the internal clocks at the Tx and Rx are not synchronized, one-way time measurements cannot be based on the difference between the transmit and receive timestamps. This is because it includes timing errors caused, among other things, by internal clock drift and non-deterministic clock offsets between the Tx and the Rx. Since the internal clocks of the Tx and Rx are not synchronized, the difference in timestamps when the signal moves in the reverse direction (i.e., from the Rx to the Tx) is affected by the clock offset in the opposite way compared to the forward direction (i.e., from the Tx to the Rx).

[0052] According to the concept of round-trip time, a data packet is transmitted from the Tx to the Rx at time t1 and received at the Rx at time t2. An affirmative response (ACK) is transmitted from the Rx to the Tx at time t3 and received at the Tx at time t4.

[0053] The round-trip time (RTT) can be obtained without the need to know any clock offset by simple addition and subtraction of the four timestamps t1 to t4 as follows. RTT = (t4 - t1 + t2 - t3) Here, t1 is the transmission time, t2 is the reception time, t3 is the positive response transmission time, and t4 is the positive response reception time.

[0054] The distance D between Tx and Rx can be estimated by using the following formula. 2*D = ((t4 - t1) - (t3 - t2)) * c Here, c is the speed of light. Also, note that no synchronization between the transmitter and the receiver is required for distance estimation based on RTT measurements. The calculation of a single distance can be extended to two-dimensional and three-dimensional spaces for the estimation of multiple distances, and then the calculation can be converted to an estimated value of location coordinates (both local and global) when the coordinates of each transmitter are known in advance. Some standardized mechanisms using RTT-based techniques include Fine Timing Measurement (FTM) defined in IEEE 802.11-2016 and Enhanced Cell ID (E-CID) defined in 3GPP (registered trademark) TS 36.133.

[0055] The Time of Flight (ToF) corresponds to the duration from when a data packet is transmitted by a transmitter (Tx, e.g., an access point / device) until the same data packet is received by a receiver (Rx, e.g., a mobile phone / device). Note that this method only considers the forward path (i.e., from Tx to Rx) and does not consider the reverse path (i.e., from 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 timestamps of the received packets are assumed to be correct and can be compensated for any timing errors caused, especially by internal clock drift and non-deterministic clock offsets between Tx and Rx. Assuming that the Tx and Rx in Figure 3 are synchronized, the distance D between Tx and Rx can be calculated by the following formula. D = (t2 - t1) * c Here, t2 is the reception timestamp, t1 is the transmission timestamp, and c is the speed of light. The time of flight can be calculated by an Rx that knows the timestamp t1 (which was included in the transmitted message, for example, or communicated later) and by its own measured timestamp t2. The time of flight can also be calculated by a Tx that knows the timestamp t2 (which was communicated later to the Tx by the Rx, for example) and by its own measured timestamp t1. The calculation of a single distance can be extended to two-dimensional and three-dimensional spaces for the estimation of multiple distances, and then the calculation can be converted to an estimated value of location coordinates (both local and global) when the coordinates of multiple reference devices (acting as either transmitters or receivers) are known in advance.

[0056] The time difference of arrival corresponds to the difference in timestamps of a data packet received by several clock-synchronized receivers (Rx, for example, access points / devices that are synchronized location reference stations), whereby the data packet was transmitted by an asynchronous transmitter (Tx, for example, a mobile phone / device, or an asynchronous location tag for which the location coordinates are to be determined). Note that the roles can be reversed, for example, the mobile phone / device may be an asynchronous Rx and the access point / device may be a synchronized transmitter. Note that a single transmission of a data packet by a transmitter is received simultaneously by several synchronized receivers located within the transmitter's coverage area. It is important that the receivers are clock-synchronized and that the location coordinates of the receivers are known to a central location server, but the transmitter for which the location coordinates are to be determined may or may not be synchronized with other transmitters or receivers. The central location server can receive the arrival times of data packets from each receiver i = 0…N and calculate the distance difference for any pair of receivers (i, j) with respect to a particular transmitter based on the following equation. Δd ij =(di -d j ) = Δt ij *c Here, c is the speed of light, and Δt ij is the difference in arrival time between receiver i and receiver j, and d i is the unknown Tx-Rx distance of receiver i, and Δd ij is the difference in Tx-Rx distance between receiver i and receiver j. The calculation can be applied to two-dimensional and three-dimensional spaces for estimating the distance difference, and the calculation can be converted to location coordinates (both local and global) when the coordinates of the receivers are known in advance. Note that the transmitter cannot calculate its own location locally on the device, and only the location server can calculate the location of the transmitter using a network of receiver nodes synchronized with the localization infrastructure. Note that the location server is located at one of the clock-synchronized receivers. The location of the transmitter can be communicated via a separate communication channel (e.g., to the application, to the transmitter, or to one or more receivers), or corrected in one of the responses from the receivers to the transmitter within the same channel used to send data packets.

[0057] Alternatively or additionally, the receiver sends its measurements (e.g., arrival time information) to the transmitter or location server instead of the calculated distance and / or angle, and the transmitter or location server calculates the resulting distance and / or determines the resulting location coordinates. Some standardized mechanisms using ToF difference-based techniques include the observed time difference of arrival (OTDOA) defined in 3GPP (registered trademark) TS 25.305 and TS 36.133, and the uplink time difference of arrival (UTDOA) defined in 3GPP (registered trademark) TS 25.305, and are typically based on position reference signals (PRS) or sounding reference signals (SRS).

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

[0059] Furthermore, the concept of the angle of arrival is based on the consideration of the phase difference. The angle of arrival of the incoming RF signal can be calculated as follows. In principle, a receiver with at least two antennas having different received phases φ1, φ2 separated by a distance d determines the phase difference Δφ of the signals received at the receiver and then uses it to estimate the angle of arrival based on the following equation. Δφ = [φ1 - φ2] = 2π[(dcosθ1) / λ] + 2kπ Here, θ1 is the angle of arrival to be estimated, k is the wave number that 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.

[0060] The angle of arrival of the RF signal at the receiver can be estimated using a naive approach based on the measured phase difference using the following equation. cosθ1 = [(Δφ / 2π) - k] * [λ / d]

[0061] In addition to the techniques described above, but not limited to, there are several well-known techniques available for calculating the angle of arrival of RF signals, including Bartlett beamforming (see M. S. Bartlett's "Smoothing Periodograms from Time-Series with Continuous Spectra"), multiple signal classification (MUSIC) (see https: / / en.wikipedia.org / wiki / MUSIC_(algorithm)), distortion estimation (see J.Capon's "High-resolution frequency-wavenumber spectrum analysis", Proceedings of IEEE, Vol. 57, issue 8), and signal noise subspace estimation. It should be noted that other complex estimations of AoA use three or more antennas at the receiver, which allows a single receiver, instead of three synchronized receivers, to obtain both angle and distance measurements based on RF signals transmitted by an asynchronous transmitter with fairly simple hardware and a single antenna. Similarly, when the transmitter uses multiple antennas, the angle of departure (of the signal at the transmitter) can be determined and used for ranging / position estimation.

[0062] The process of obtaining the location coordinates of a device and placing the device on a map using a mapping function is also provided by the Location Service (LCS) offered in the 3GPP (registered trademark) system, where the base station acts as a synchronization source, and the location coordinates of the device are obtained based on radio parameters and special messages using various positioning methods described, for example, in 3GPP (registered trademark) specification TS 23.271 "Functional stage 2 description of Location Services (LCS)", Rel-16 for 4G, and 3GPP (registered trademark) specification TS 23.273 "5G System (5GS) Location Services (LCS); Stage 2", Rel-17 for 5G.

[0063] Typical differences between the location service and the ranging service provided by the 3GPP (registered trademark) system are as follows. The location service measures the geographical coordinates of a device within the coverage area of a cell (e.g., 1 to 5 km) and provides good accuracy in an outdoor environment. In an outdoor environment, a line of sight (LOS) to a base station is possible, the communication path can be properly modeled, and it can be considered to use channel models for urban and rural environments. On the other hand, the ranging service measures the distance and / or angle between two devices within a short distance (e.g., 20 m) and provides good accuracy in an outdoor environment, especially an indoor environment, where the two ranging devices are also in line of sight (LOS) with each other.

[0064] For example, in order to provide a location service with improved accuracy and better indoor location estimation, the functions of the location service and the ranging service are combined.

[0065] It should be noted that the location service can also be provided as part of a ranging service where, for example, the locations of two devices can be observed / judged through, for example, GNSS, the distance and / or angle between the two devices can be calculated, and the device is enabled to request its distance and / or angle to another device. In such a case, the two devices are still required to perform ranging measurements between each other to improve the accuracy of the distance and / or angle between the two devices or to determine the deviation with respect to the observed / judged location.

[0066] The conversion from distance to coordinates can be achieved, for example, based on ranging measurements where the first device A can obtain the distance (d) and angle (tc) towards the second device B. If the coordinates of device A are known and its orientation with respect to the coordinate system is known, the measured values of the distance and angle between device A and device B can be used by device A to obtain the coordinates of device B.

[0067] For example, in the case of geographical coordinates expressed in radians, it is assumed that the latitude (lat1) and longitude (lon1) of device A are known. Then, the geographical coordinates (lat2, lon2) of device B can be calculated using the following equations when using the spherical Earth approximation model. lat2 = asin(sin(lat1) * cos(d) + cos(lat1) * sin(d) * cos(tc)) dlon = atan2([sin(tc) * sin(d) * cos(lat1)], [cos(d) - sin(lat1) * sin(lat2)]) lon2 = [mod(lon1 - dlon + π, 2 * π)] - π

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

[0069] As another example, in the case of a local 2D Cartesian coordinate system used for an area, it is assumed that the X and Y coordinates (x1 and y1 respectively) of device A are known. Then, the X / Y location coordinates (x2 and y2 respectively) of device B can be calculated using the following equations. x2 = d * cos(alpha) + x1 y2 = d * sin(alpha) + y1 Here, all coordinates and the distance d are expressed in meters, and the angle (alpha) towards device B is measured by A.

[0070] Alternatively, the conversion from distance to coordinates in a coordinate system is performed using other concepts such as the inverse Haversine formula, length of one degree, Molodensky method, and block shift method, depending on the required accuracy and the type of coordinate system used in the application.

[0071] Current techniques for ranging and position estimation can be improved in the following areas. i. Location accuracy highly depends on signal path loss and degrades along with the loss of signal quality in indoor environments with very poor or deep indoor cellular coverage. Furthermore, in remote outdoor environments where the number of base stations is limited and as a result there is little or no signal coverage, the accuracy of location services deteriorates. In such areas, depending on the positioning method used, trilateration or triangulation of a mobile device (e.g., UE) requires a longer initial latching time to be able to simultaneously receive at least three different signals from at least three different base stations. When a mobile device is moving within such a poor coverage area, the continuity and reliability of the location service provided by the base station significantly deteriorate, and as a result, the service becomes unavailable for real-time location tracking. ii. Ranging accuracy in outdoor environments highly depends on the channel variability and the reflection characteristics of the objects surrounding the device performing the ranging operation. In indoor environments, the user of a mobile device (e.g., UE) can properly control the environment with respect to the objects and the surrounding environment before ranging between two devices, but in outdoor environments, controlling the environment is uncertain and often affects the ranging accuracy negatively. In addition, the movement of a mobile device in outdoor environments also significantly affects the ranging accuracy due to the possible Doppler effect in the RF propagation channel. Therefore, due to the highly deteriorating effects in the RF channel, ranging measurements between two devices in outdoor environments become unusable.

[0072] Some use cases require the conversion of ranging measurements to location coordinates, which enables a UE that cannot use a positioning service or an additional positioning module to obtain location coordinates derived from ranging information. In addition, devices with very poor positioning accuracy, especially in indoor environments, benefit from ranging, so the positioning accuracy improves from hundreds of meters to less than a meter in indoor environments and / or out-of-coverage environments. Furthermore, accurate positioning and continuous tracking of low-power IoT devices are requirements for yet another use case, which can enable the adaptive delivery of quality of service (QoS), e.g., depending on the location, a high bandwidth is provided to a mobile UE at location X, but only a low bandwidth is provided at location Y. Some of the identified preferred use cases require the formation of clusters of UEs based on location information in order to distribute location-based QoS to a group of UEs.

[0073] Throughout the present disclosure, where the concepts of ranging and / or positioning are mentioned, it is important to note that any one of the above ranging methods and / or positioning methods, or a combination thereof, or other ranging methods or positioning methods known to those skilled in the art may be used.

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

[0075] "Energy-Efficient Dynamic Clustering for IoT Applications: A Neural Network Approach" by Li Manman et al., IEEE Eighth International Conference on Communications and Networking (ComNet), October 27 - 30, 2020 (DOI: 10.1109 / ComNet47917.2020.9306092) describes the use of dynamic clustering for energy-efficient data transmission in Internet of Things (IoT) networks. Neural networks and copula theory are used to process the amount of information based on the power demand by individual clusters. This avoids the redundancy of information and waste of resources caused by the repetitive structure of the same type of clusters (as in the case of conventional methods). According to the power requirements, nodes are divided into two initial clusters based on the application, compared with a set threshold. These are then used to assign logical values to the nodes within the cluster, thereby effectively utilizing the information within the cluster and taking a balanced coordinated communication energy between clusters for IoT applications.

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

[0077] In the context of "platoon driving" of smart devices (e.g., autonomous vehicles), similar behavior has also been investigated in "Emergent Behaviors in Internet of Things: The Ultimate Ultra-Large-Scale System" by Damian Roca et al., IEEE MICRO, SPECIAL ISSUE IOT.

[0078] More broadly, many types of soft information (such as specific network access) have been proposed for the localization of things (LoT).

[0079] According to various embodiments, a low-power asset tracker of a tracker control system (or tracking system) enables other nearby asset trackers to "contact trace" each other in a protocol that allows, for example, the range of contact tracing and other parameters to be at least partially determined by a network-side entity based only on intermittent communication with a subset of the trackers, while still allowing a central server in the telecommunications network to calculate the location of the trackers, and to reduce the number of network transmissions and / or the energy cost of the trackers.

[0080] Note that the purpose of communication with the asset tracker is at least one of calculating / estimating the tracker location, searching for identification information, searching for asset types, and searching for sensed values.

[0081] Note further that the optimization goal is not only reduced energy or fewer network transmissions. The optimization goal can also be lower latency (since there is no multi-hop communication) and / or higher reliability (since all or more trackers are reachable).

[0082] By controlling the transmission power, and thus the distance range within which an asset tracker registers additional contacts, a network-side server or application can maintain and operate a statistical model that provides location and other details (such as usage status) for each tracker.

[0083] Various embodiments are described below. Further details of their hardware components are described later with reference to FIG. 1, and further details of their procedure steps and signaling steps are described later with reference to FIGS. 2 through 5.

[0084] Upon initial power-up, or as needed during use, an asset tracker enters a provisioning mode. In the provisioning mode, the asset tracker attempts to discover a network and / or a part of a cluster, and a local tracker that broadcasts a synchronization signal (e.g., by listening for a synchronization signal and a master information block (MIB), a system information block (SIB), or a beacon from a nearby access device), such as a synchronization reference UE (SyncRef UE) defined in 3GPP (registered trademark) specification TS 38.133 or an alternative implementation that provides a similar function. For simplicity, the term "SyncRef UE" is used in the following description, but this also means an alternative implementation that provides a similar or related function, e.g., a UE that provides a discovery signal or a synchronization signal via sidelink / D2D communication, or a UE-network relay device that provides an SIB / MIB via ProSe relay communication.

[0085] When the asset tracker has found a suitable network or SyncRef UE and / or has set up provisioning by receiving suitable basic communication scheduling, the network (or cluster head) provides data specific to the system to the asset tracker, which data includes the intended sleep / wake cycle, tracking range, and / or other setup details (e.g., the portion of the wake cycle for transmitting uplink communication to the network).

[0086] The asset tracker transmits identification information (ID) via the local area protocol using the received transmission details, either individually or as part of a cluster. The asset tracker also listens for the received ID. The ID is configured during the above setup or during manufacturing and is expected to be unique within the context of the local area protocol.

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

[0088] When the asset tracker is within the network coverage area (covered), the asset tracker (or the cluster head if the asset tracker is within an existing cluster) reports to the network, after a scheduled delay time (which can be configured or pre-set by the network), its own ID, the IDs it has received, and (if available) its location, a parameter indicating signal strength (such as Received Signal Strength Indicator (RSSI) or Reference Signal Received Power (RSRP)), or a parameter indicating position, distance, angle, or a measurement of position, distance, or angle (e.g., coordinates in a coordinate reference system, distance in meters, angle in degrees relative to a reference direction / reference line, or TDOA timing), and / or optionally other details such as battery life (as described in detail below). This type of information should be understood as an example of "location information" or "location-related information".

[0089] The network-side model or application maintained in the network uses the trackers of some assets (e.g., syncRef UE or anchor nodes) or the received IDs and / or known locations of gNBs to calculate the known or inferred locations of the trackers of all assets (including trackers of any "invisible" assets) at each time step. In some cases, for example, when the calculated location of the tracker of an invisible asset appears to be near the location of the tracker of the most recently reported asset or when the number of received IDs is less than the expected number of IDs, the network optionally contacts each of the relevant asset trackers and instructs those asset trackers to modify their tracking ranges, modify their sleep / wake behavior, reduce the number of uplink transmissions, and / or form clusters. By doing so, the network-side model or application optimizes, for example, between location certainty and / or energy usage of the asset trackers (e.g., by reducing the frequency and range of uplink transmissions) and / or reliability.

[0090] The network maintains the current estimated location of the asset trackers, the clusters, and the status data (e.g., battery life and / or energy production status of integrated energy harvesting elements) provided (served) to the appropriate application. This is done continuously or based on a (one-time-only) request.

[0091] When the asset tracker is outside the network coverage area (out of coverage) and is already part of a cluster, the asset tracker continues to operate under cluster mode. Note that some of the asset trackers in the cluster are within coverage, while other asset trackers in the same cluster are outside coverage. The goal is to maintain knowledge of the cluster members and for the asset tracker to remain discoverable by any network in case it enters coverage after at least a certain delay period.

[0092] One of the asset trackers in the cluster acts as the source of the cluster synchronization signal (i.e., the asset tracker functions as a SyncRef UE). This task is dynamically shared among the cluster trackers based on battery or hardware considerations.

[0093] When the asset tracker is outside the network coverage area (out-of-coverage) and not part of a cluster, the asset tracker becomes an isolated asset tracker. In this case, the asset tracker uses the latest available settings to broadcast other relevant information such as its (protected) ID and / or pseudo-ID and / or tracker characteristics, and listens for any nearby network or cluster head (for the purpose of joining the network cell or cluster). The broadcast is triggered upon receipt of a triggering signal (e.g., discovery message or synchronization message) from a nearby tracker (e.g., UE) or access device. "Protected" means encrypted (e.g., by an NR encryption algorithm such as NEA1) and / or "integrity protected" (e.g., by an NR integrity algorithm such as NIA1). For the remainder of this specification, without loss of generality, it is said that the asset broadcasts its ID. The likelihood of discovery of an isolated asset tracker can be a trade-off for battery usage by changing the relative time and / or transmit power that the asset tracker spends with an active receiver (Rx on). Alternatively or additionally, the asset tracker uses Model A or Model B ProSe discovery to send a Model A notification message or Model B request message to and / or listen for a Model B response message to an incoming Model A notification message or request message via sidelink with a UE or another asset tracker (which may or may not be part of a cluster). Such discovery messages include a service identifier (e.g., a ProSe identifier indicating the asset tracking service), a device identifier (e.g., a pseudo-ID of the asset tracker or another UE / asset tracker), an attribute / flag indicating the capabilities / requirements for asset tracking, and / or an identifier (e.g., a ProSe identifier indicating the cluster formation service) or an attribute / flag indicating the capabilities / requirements for forming a cluster. After discovery by another UE / asset tracker, the asset tracker is added to a cluster or a new cluster is formed.The asset tracker or another UE / asset tracker sends one or more messages (e.g., through a direct communication request message) to request / confirm the addition / formation of a cluster, whereby the message includes information about the cluster (e.g., cluster ID). Additionally or alternatively, asset tracking is performed by, for example, reporting the observations and / or location of the asset tracker or other UE / asset tracker to the network or to yet another asset tracker (e.g., based on information obtained from discovery messages including signal strength determination for distance estimation, and / or based on a subsequent set of messages between the asset tracker and other UE / asset tracker and / or the network or yet another asset tracker).

[0094] Furthermore, the communication frequency and other settings are automatically changed by the asset tracker or cluster based on a context cue (e.g., they "wake up" when movement is detected or enter "storage mode" when the same cluster members are repeatedly observed).

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

[0096] Individual asset trackers and / or cluster heads retain received IDs in memory when they are outside the network coverage and report those IDs when they are able to do so (e.g., when they regain network coverage).

[0097] Optionally, the network attempts to contact the cluster head by using any available nearby asset tracker (e.g., by temporarily expanding their tracking range) to actively search for clusters that are outside the coverage.

[0098] Accordingly, according to various embodiments, an asset tracker control system (asset tracking system) is provided. In this system, the asset tracker uses a low transmit power local "contact tracing" protocol that is complemented by less frequent contact with the network, enabling the network-side model or application to hold information about the location of the asset tracker while saving energy.

[0099] The contact tracing protocol can be adapted to save energy in at least one of the following three ways. i. The contact tracing protocol is configured to reduce, on average, the number and / or range of uplink communications required for any given asset tracker. ii. The contact tracing protocol is configured to allow network-controlled or cluster-controlled sleep periods (set to be longer than the wake periods), and the trade-off between the length of the sleep period and location accuracy can be controlled by the network or cluster head. iii. The contact tracing protocol is configured to allow the asset trackers within the cluster to maintain contact with the network (e.g., in cluster mode) by delegating the task of maintaining contact to the asset tracker with the longest remaining battery life.

[0100] In one embodiment, the contact tracing protocol is further configured to allow the network-side model (and / or local asset trackers such as cluster heads) to optimize between location discovery, battery life, and other considerations by changing the tracking range and sleep / wake cycle of the asset tracker. Optionally, these parameters are changed / adjusted independently by the asset tracker based on data such as location, detected movement, etc.

[0101] In a further embodiment, the asset tracking system is configured to retain at least some functionality even when outside of network coverage by enabling the clustering of asset trackers to be provisioned and maintained in such a way that the clusters are discoverable to the tracking system when appropriate and report information about contacts that occurred between an asset tracker and other asset trackers while out of coverage, information that would otherwise not be available to the network.

[0102] FIG. 1 schematically shows a block diagram of an asset tracking system (asset tracker control system) according to various embodiments.

[0103] Each of the plurality of trackers (TR) 102 in the asset tracker group (AT) 10 of the tracking system comprises asset tracking hardware capable of communicating over a telecommunications network (e.g., a 3GPP® 5G network or other wireless network), and the asset tracking hardware is attached to a physical object whose location (and possibly other information such as usage status) is to be tracked during use. More specifically, each tracker 102 includes the necessary networking hardware and software in addition to other hardware such as a battery, an antenna, a central processing unit (CPU), and optional additional hardware such as inertial sensors, additional location sensors, environmental sensors. The tracker uses energy harvesting to collect sufficient energy for communication, which causes significant delays between messages and significant delays in message responses. The tracker also supports backscatter-based communication. In backscatter communication, information (e.g., an uplink or sidelink communication message) is modulated onto an incoming collision signal (e.g., an illuminating RF signal) from (e.g., a base station or other UE), such that the modulated signal is reflected / transmitted so that a nearby base station or other UE can receive the modulated signal.

[0104] Furthermore, each tracker 102 is configured to support various operating modes, including a "sleep" period during which the radio frequency (RF) process and other networking processes of the tracker 102 are substantially shut down or in an idle mode or power saving mode, with at least the local clock remaining operational, and a "wake" period during which at least a part of the tracker hardware is active to enable the desired functionality.

[0105] As initially described, the tracker 102 is configured to communicate using both a standard uplink protocol and / or downlink protocol and a device-to-device (D2D) protocol. The transmit power used for D2D communication is variable and is used to modify the range ("tracking range") within which a tracker of a nearby asset is expected to be able to receive a D2D signal from the tracker 102.

[0106] Optionally, the tracker 102 is capable of more advanced ranging techniques, such as two-way ranging, as initially described.

[0107] Optionally, hardware with additional capabilities, such as an installer's UE (I-UE) 40 or other mobile device, is used by the installer during the provisioning process, as described later. An example of suitable hardware for the installer's UE includes a smartphone or laptop with network access.

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

[0109] The network 20 is a telecommunications network such as a 5G network, and the asset tracker 10 is within the range ("coverage") of the network 20 or outside its range ("out of coverage").

[0110] Network 20 provides services to (mobile) devices (e.g., 5G UEs) by using base stations (e.g., 5G NR gNBs or LTE eNBs).

[0111] In addition to normal RF components, Network 20 includes suitable computing hardware and software for executing a statistical model (e.g., Network-Side Model 202) based on, for example, the location or approximate location of Tracker 102 of Asset Tracker Group 10.

[0112] Network-Side Model 202 is hosted in a network function of Network 20, such as a network function of the 3GPP® 5G core network (e.g., a location service such as a Location Management Function (LMF)), an application function integrated through a (Service-Based Architecture (SBA) interface), or an external application connected to the core network through a Network Exposure Function (NEF).

[0113] Data obtained from Network 20 and the Network-Side Model, related to them, and / or required by them is stored in a Tracker Position Database (TP-DB) 204, and the Tracker Position Database (TP-DB) 20 provides (surfaces) the data to suitable authorized applications and / or other downstream Location Data Clients (LD-CLs) 30 (e.g., installed and / or used by the owner of Tracker 102) as required.

[0114] In addition, the asset tracking system includes a cluster (CL) 106 that is a group of at least two cluster trackers (CL-TR) 1066 physically collocated within a certain distance (the "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 is configured as a cluster head (CLH) 1062 that has the additional responsibility of maintaining information (membership information) about the members of the cluster 106 and reporting that information to the network 20 when requested or scheduled.

[0115] The cluster range is related to the transmission power used by the cluster trackers 1066 within the cluster 106 to communicate and is modified by changing the corresponding parameters.

[0116] Optionally, ranging techniques more advanced than simple signal strength measurements (including any suitable trilateration or localization techniques as described initially) are used to define and control the cluster range.

[0117] The cluster 106 exists either fully within coverage (i.e., all cluster trackers 1066 of the cluster 106 are within the coverage area of the network 20, e.g., a network cell), partially within coverage (some cluster trackers 1066 of the cluster 106 are within coverage while others are outside coverage), or completely outside the coverage of the network 20.

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

[0119] In one embodiment, the role of SyncRef UE 1064 corresponds to the role defined in 3GPP (registered trademark) specification TS 38.133 (and elsewhere).

[0120] In another embodiment, the role of the synchronization reference is a lower power implementation form, such as an alternative role, for example, providing a time synchronization reference signal to other cluster trackers 1066.

[0121] SyncRef UE 1064 is selected such that it is a cluster tracker 1066 having higher accuracy timing available even when it is outside the coverage of network 20 (for example, by making a Global Navigation Satellite System (GNSS) chip available).

[0122] When cluster 106 is within partial network coverage, it is preferred that the roles of SyncRef UE 1064 and cluster head 1062 are taken over by one of the cluster trackers 1066 within network coverage. This enables SyncRef UE 1064 to synchronize not only the entire cluster 106 with network 20 but also locally, and enables all cluster trackers 1066 within cluster 106 to maintain contact with network 20 through cluster head 1062.

[0123] When multiple cluster trackers 1066 within the same cluster 106 are within coverage, they select a suitable SyncRef UE 1064 and cluster head 1062 from the cluster trackers 1066 within coverage, as will be described later in the section on the cluster mode of the main use phase procedure.

[0124] Trackers that are not part of cluster 106 but are otherwise fully functional are called "isolated trackers" (ITR) 104 when they are outside the coverage of network 20.

[0125] The process for localizing the tracker is described below with reference to FIGS. 2 to 4.

[0126] The process is designed to conserve energy in the trackers 102, cluster trackers 1066 and / or isolated trackers 104, for example, by reducing the number and frequency of their uplink transmissions (and the time of receiving downlink information), and thus extending the life of battery-powered trackers or enabling battery-less trackers. The process is also designed to retain at least some functionality when the tracker is outside the coverage of network 20.

[0127] In an embodiment, the process for localizing includes two stages with associated sub-processes, namely, an initial provisioning stage and a main use (tracking) stage.

[0128] Note that both sub-processes proceed differently depending on whether the tracker in question is within the coverage of network 20, partially within the coverage, or outside the coverage.

[0129] FIG. 2 schematically shows a diagram of signaling and processing for an initial provisioning process according to an embodiment.

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

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

[0132] In addition to the initial power-on, the tracker 102 is configured to automatically re-enter the provisioning mode during the main usage phase as needed (e.g., after re-entering the network coverage following a period outside the coverage).

[0133] The tracker 102 can also be manually reset to the provisioning mode by an external operation (e.g., using the installer's UE40). This is required, for example, to register a change in the ownership or status of the tracker 102.

[0134] The registration of the tracker 102 to the network 20 is based on network credentials or application-specific credentials that may require at least tracker identification information and / or secret key material.

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

[0136] Optionally, in an embodiment, the tracker 102 is configured to select the use of the cluster provisioning mode (CL-PM) in some scenarios even when the tracker 102 is within the coverage of the network 20. As an example, cluster provisioning is relevant when a large number of trackers 102 are to be provisioned at once and / or when a high degree of mobility (and thus a high likelihood of coverage loss) is expected for the tracker 102, e.g., in the case of a pallet of goods on a truck where each box contains a tracker 102. In such a case, the installer's UE40 decides to configure the tracker 102 to use the cluster provisioning mode even when network contact is available.

[0137] In step S203, the tracker checks whether it is within the coverage (IC) of network 20. If it is determined that network contact is possible, the tracker 102 contacts network 20 in step S205 via an existing long - distance protocol under, for example, 5G or any other wireless communication standard. Standard uplink / downlink communication protocols as well as dedicated protocols (e.g., NB - IoT) are used. Generally, a long - distance protocol refers to a protocol that enables direct wireless communication of the tracker with an access device connected to the core network, such as an access point or a base station.

[0138] Furthermore, in step S205, the tracker communicates to network 20 its data including a unique ID number or identification information (e.g., a subscription concealment identifier (SUCI), see TS 33.501) derived from unique device identification information (e.g., a subscription permanent identifier (SUPI) or international mobile subscriber identification information (IMSI), etc.) of the tracker, and any available installation or usage data (such as location, owner, physical asset it is associated with, dedicated hardware resources, remaining battery life, i.e., "metadata", etc.).

[0139] In an embodiment, the ID is permanently associated with the tracker 102 at the time of manufacture (e.g., stored on the hardware of the tracker 102 or on a (embedded) smart card that can be connected to the hardware). This option reduces complexity, for example, by using the international mobile equipment identity (IMEI) number of the tracker, but is accompanied by security and / or privacy issues due to the inability to change the ID after any data breach.

[0140] In other embodiments, the ID is generated either sequentially or according to any other suitable pattern during the provisioning process (e.g., during the provisioning of policies and permissions by a Policy Control Function (PCF)) by the tracker 102 or by the network 20. Any algorithm for generating the ID must ensure that the ID is unique across all trackers that are members of the asset tracker group 10 or cluster 106. In the following text, the term "unique ID" is used to denote an ID that is at least unique within the asset tracker group 10 or cluster 106.

[0141] In one example, the unique ID is the user information ID exchanged in a direct communication request (DCR) message on PC5 / sidelink.

[0142] The advantage of dynamically generating unique IDs is that in the event of a data breach, the tracker 102 can "reset" those unique IDs without any hardware changes.

[0143] In one embodiment, the tracker 102 sets a logical flag during any subsequent return to the provisioning mode, and this return is made after a loss of network coverage to notify the network 20 that it does not require a new random ID as the unique ID (to avoid accidental loss of information).

[0144] In one embodiment, the unique ID is generated by each tracker 102 by deriving the unique ID from a unique device identifier (e.g., SUPI / IMSI / IMEI) in a similar way as, for example, deriving a Subscriber Concealed Identifier (SUCI), such that the core network (e.g., Authentication Server Function (AUSF) or in the case of SUCI, Unified Data Management (UDM)) can decrypt the identification information (e.g., SUPI) of the tracker from which the unique ID was derived. In one embodiment, the unique ID is generated or protected by each tracker 102 by a pseudo-random number generation function (whereby the function / algorithm / configuration option is predefined, preconfigured, or downloaded on the tracker 102, e.g., by / from the network or by / from the installer's UE), such that the pseudo-random number generation function takes a time reference (e.g., Coordinated Universal Time (UTC)) as an input and / or whereby the identifier that identifies the pseudo-random number generation function or a particular pseudo-random number generation function and by which its input is used by that function is shared with the network, the cluster head, and / or other trackers, such that if the same input is applied, they can come up with the same ID).

[0145] Optionally, the unique ID is prepended (added at the beginning), appended (added), or multiplexed with the identification information of the tracker group of the cluster / asset.

[0146] In a further embodiment, the unique ID is assigned to the tracker 102 by the installer (e.g., using the installer's UE40) before provisioning using the order algorithm or other algorithms described above.

[0147] Optionally, the unique ID is more difficult to protect from privacy attacks, tracking attacks, etc. The way to protect the unique ID is by encryption (e.g., using a public key system), and as a result, the unique ID transmitted by tracker 102 can only be decrypted by the network-side model 202 (which holds the appropriate private key), rather than by any intermediate tracker that receives it.

[0148] In subsequent step S206, network 20 communicates data to tracker 102 that includes synchronization, timing, and timing / frequency resources (e.g., sleep and wake (S / W) times) that will be used to communicate with other trackers that are known or expected to be nearby. Network 20 also communicates other parameters such as group identifiers and / or security key material to enable secure communication within the group.

[0149] Optionally, if a suitable default data set is already stored in tracker 102, step S206 can be skipped.

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

[0151] The remaining synchronization and resource allocation required for communication while in coverage is substantially handled by network 20 using existing protocols (e.g., standard communication or NB-IoT).

[0152] Optionally, in step S207, the tracker is instructed by the network 20 to participate in cluster 106 by using the cluster provisioning mode. As an example, this applies when the tracker 102 is already a member of cluster 106 before the first network contact. In this case, one of the trackers in the asset tracker group 10 (preferably the cluster head 1062) reports the details of the unique ID for all trackers 1066 in the entire cluster 106.

[0153] Optionally, the cluster ID is dynamically assigned to cluster 106 by the network 20 or the installer's UE40 to assist in tracking. Similar to the individual unique ID of the tracker 102, the cluster ID has an encryption function or security function associated with it. For example, a so-called cluster key is assigned to bind to the unique ID for which the message integrity code (MIC) is exchanged, which enables the cluster head 1062 to verify that their unique IDs are valid. The cluster key is a group key or a pairwise key between each pair of cluster trackers 1066.

[0154] Upon receiving the required sleep / wake cycle and other data, the tracker 102 starts in step S213 to broadcast its unique ID (periodically) as instructed, and the procedure proceeds to the main use stage (M).

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

[0156] If the tracker 102 was not previously part of the cluster 106 (e.g., initial provisioning of an isolated tracker), it becomes an isolated tracker 104, sets its receiver to be active on a relevant (e.g., default and / or pre-configured) frequency band, remains active for a given length of time, and attempts to discover any nearby cluster 106 or network 20 by searching for synchronization signals from any SyncRef UE 1064 or network 20. The length of time to remain active is either selected from a predetermined set or automatically configured by the isolated tracker 104.

[0157] The longer the isolated tracker 104 remains active at the expense of (energy) resource usage, the higher the likelihood of discovering the cluster 106. In one example, to facilitate discovery by the isolated tracker 104, a default minimum time may be specified during which a tracker acting as the SyncRef UE 1064 of any cluster 106 must be in the wake mode (even if the remaining trackers 1066 within the cluster 106 are not scheduled in the wake mode). For example, if this time is once an hour, any isolated tracker 104 only needs to remain active for one hour.

[0158] If the isolated tracker 104 detects the SyncRef UE 1064, it uses the information received from the SyncRef UE in the synchronization signal (SYNC) in step S208 and contacts the cluster head 1062 to join the cluster 106 in step S209, providing its unique ID and metadata.

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

[0160] Otherwise, if the isolated tracker does not discover the SyncRef UE1064 in step S204 during its active period, it will retry provisioning at defined intervals or immediately in the case of some detected events indicating that it is likely to have moved (e.g., movement, or a change in temperature above a threshold).

[0161] As another option, the isolated tracker 104 also attempts to actively contact any nearby SyncRef UE1064. This is achieved, for example, by broadcasting its own SyncRef UE signal at high power. Any nearby SyncRef UE1064, when receiving such a signal, temporarily increases its own transmission power to enable the isolated tracker 104 to join the cluster 106 as described above in relation to steps S208 to S210.

[0162] The power level and repetition timing of such an active broadcast by the isolated tracker 104 balance its remaining battery life and its estimate of the likelihood that there are nearby trackers to be discovered (e.g., indicating that the isolated tracker 104 may have just gone out of range as it was part of the cluster 106 during the last wake period).

[0163] In an embodiment, to facilitate cluster discovery by the isolated tracker 104 in step S204, a set of default frequency resources is reserved for use by the SyncRef UE1064 in an out-of-coverage state, similar to the reserved resources used for semi-persistent scheduling of mode 3 or mode 4 V2X (e.g., in 3GPP™ specification TS 36.331 and elsewhere).

[0164] If the isolated tracker 104 was previously (within the most recent time period in which it could be configured) part of the cluster 106, the isolated tracker 104 preferably attempts to specifically rediscover its previous cluster 106 in step S204 before attempting to discover other clusters using the above options. This scenario occurs, for example, because the isolated tracker 104 has left the cluster 106, or because the isolated tracker 104 acting as the SyncRef UE1064 has left the cluster 106, and thus the entire cluster 106 has lost synchronization during its wake period even though most of the cluster trackers 1066 are still collocated.

[0165] In one embodiment, the isolated tracker 104 follows a sequential procedure to attempt to re - establish contact with the cluster 106 in step S204, where the last - used SyncRef UE1064 attempts to re - establish signaling for a given time period, followed by other UEs in accordance with an ordered list.

[0166] In this way, any given cluster tracker 1066 within the cluster 106 should be able to calculate how long (up to what maximum time) a synchronization reference signal can be received (visibly) after failing to attempt communication during the wake period. If no synchronization reference signal is received during the entire period up to that maximum time, the cluster tracker 1066 will know that it should become the SyncRef UE1064 itself.

[0167] In one embodiment, a random delay is added to the duration of each re - connection attempt to avoid any potential crashes between two trackers having the same priority level in the list. In this case, the upper limit of the delay is set to the maximum amount so that the tracker can still apply the maximum wait period calculation as described above.

[0168] After waiting for the maximum time predicted based on the number of devices within cluster 106 and its own position within the order, the cluster tracker 1066 determines that it is an isolated tracker 104 and can return to the relevant procedure steps.

[0169] If network contact is not possible and the isolated tracker 104 was not previously part of a cluster, the procedure branches to step S211, where a nearby installer's UE40 is activated to be used for manual provisioning (MP) and to act as a SyncRef UE and cluster head to register the unique ID of the isolated tracker 104 and provide sleep / wake information and communication details or information about the cluster (e.g., cluster identification information, cluster credentials) to the isolated tracker 104 in step S212. For example, a group of trackers 102 is manually provisioned for the first time, and the operating system uses a smartphone to enable them to form a cluster 106 even if the trackers 102 are in an out-of-coverage state and none of them are acting as SyncRef UE1064.

[0170] The procedure of the provisioning stage described above is repeated as required by the tracker 102 or as commanded by the network 20.

[0171] FIG. 3 schematically shows a diagram of signaling and processing for the main use stage or tracking stage according to an embodiment.

[0172] Upon completion of the provisioning process, the tracker 102 starts the main use stage (MUP) in step S301 and starts contact tracing in several modes including a stand-alone mode (activated only in the in-coverage state of the tracker) and a cluster mode (activated in the in-coverage state or in the out-of-coverage state of the tracker).

[0173] The provisioned tracker 102 wakes up (enters the wake period) in step S302 and detects its network environment for any synchronization signal (SYNC) in step S303. Based on the detection step S303, the tracker 102 determines in step S304 whether it is within the coverage area of the network (NW) 20 (coverage-in state).

[0174] If it is within the coverage area, the tracker 102 determines in step S305 whether it is set to the stand-alone mode (SAM) or the cluster mode (CLM).

[0175] If the stand-alone mode is activated or step S305 is skipped, the procedure branches to step S307, where the tracker 102 transmits (reports) its unique ID and optional metadata to the network 20 or another device that transfers information to the network via D2D communication, enters the sleep cycle (period) set during the provisioning phase and / or updated by the network during the main use phase, listens for the received unique ID during the wake cycle (period), whereby the sleep and wake (S / W) timing, synchronization, and resource allocation are handled by the network 20 based on the existing protocol as described initially, for example.

[0176] In some embodiments, the tracker 102 uses one of the available synchronization signals provided by the network 20 to organize the communication and broadcasts its unique ID during the wake cycle using the existing D2D protocol (as described initially, for example). The tracker 102 also listens for the received IDs of other trackers, stores each received ID together with a timestamp, and in addition, stores an estimated value of the received signal strength of the D2D transmission.

[0177] Optionally, the tracker 102 uses additional ranging information, together with or instead of the received signal strength (RSS), to label the received ID. This includes two-way ranging techniques for the associated tracker (e.g., as described initially). This option is expected to give each tracker better accuracy with respect to range, at the expense of potentially increased power consumption. Optionally, the tracker 102 advertises its ability for two-way ranging as part of the transmitted metadata, to enable it to attempt two-way ranging only with other trackers that are known to be capable of it. Labeling the received ID is achieved, for example, by tagging the received ID information with metadata, which is additional ranging information, additional RSS / RSSI / RSRP information, or both of these types of information.

[0178] Optionally, each tracker 102 performs RF signal measurements or processes received MIB / SIB / sidelink synchronization signals / PC5 discovery messages, and includes as part of the information shared with other trackers information such as cell ID, tracking area identifier (TAI), RSRP of neighboring cells, layer 2 or other identifiers received via the PC5 discovery message and / or signal strength of the sidelink synchronization signal / PC5 discovery message and / or signal strengths of different beams used by / received from access devices or other trackers (e.g., indicated by the signal synchronization block (SSB) index) and / or information about which beam has the highest signal strength. This information is transmitted to the network and taken into account by the network-side model 202 to identify the position of the tracker.

[0179] Optionally, tracker 102 also listens for commands from network 20 or network-side model 202 during its wake cycle. The network-side model 202 receives the tracker ID and metadata from network 20 in step S312, and in step S313, if necessary, expands the tracking range (TRR), changes the sleep / wake cycle (S / W), and / or commands tracker 102 to participate in a cluster (CL).

[0180] Optionally, network 20 also sets (selected or all) trackers to listen mode. In this mode, the trackers wait until they receive a request to which they should respond with their unique ID. Trackers directly connected to network 20 forward the request to other out-of-coverage trackers.

[0181] In one embodiment, during some portions of the wake cycle, or during a dedicated wake cycle optionally reserved for uplink communication to network 20, tracker 102 reports data to network 20 (e.g., in step S307), the data including at least one of its unique ID, the D2D transmit signal power used by tracker 102 during the last wake cycle (i.e., the tracking range of the tracker logged for each individual transmission if the power changed during the wake cycle), its location if available (e.g., via GNSS), and any received unique ID, signal strength, and metadata linked to those transmissions.

[0182] In one embodiment, tracker 102 reports, e.g., in step S307, all unique IDs and the associated signal strengths and / or metadata observed since the last known and / or positively responded network contact (regardless of whether this is one wake cycle or several wake cycles). The unique IDs are labeled with timestamps so that the network-side model 202 can calculate the order in which the unique IDs were received.

[0183] Optionally, the tracker 102 reports only those unique IDs from the last wake cycle of a specific number n or the most recently received unique IDs of a specific number m (where n and m are defined based on optimizing memory usage versus location certainty in the network-side model 202).

[0184] In one embodiment, the portion of the wake cycle that will be used for network reporting in step S307 is initially set to 100% or any other portion. The network-side model 202 instructs the tracker to modify (i.e., reduce) this portion in order to conserve power by restricting long-range transmissions per unit time as its location certainty for the tracker increases (i.e., the network-side model 202 instructs to reduce the transmission power of the unique ID transmissions).

[0185] In one embodiment, the portion of the wake cycle used for network reporting in step S307 is also modified by the tracker itself. For example, if the tracker does not receive a new unique ID during the wake cycle (presumably indicating a static location or cluster membership), it optionally reduces its network reporting portion to conserve power (in such a scenario, the network 20 and / or the local tracker 102 are configured to form clusters as will be described later).

[0186] Note that if the tracker does not receive a new unique ID but only a subset of the known unique IDs, the tracker reports that one or more of the previously known unique IDs are missing (as this gives the network 20 an indication that those trackers having those unique IDs are now in different locations), that there is no battery power left, that it is in a different (wireless) environment, or that it is now out of coverage, etc.

[0187] In one embodiment, the tracker 102 reports, for example, in step S307, only the ID and the associated signal strength and / or metadata that has been newly observed or not observed since the last known and / or positively responded network contact. For this purpose, the tracker 102 maintains information about a list of other trackers that have been previously discovered and / or information about which trackers have already been reported to the network. This reduces the amount of data or the frequency with which the data needs to be sent to the network. At some point, the network relies on the trackers to report all the other observed trackers in order to update / refresh the information known by the network or application and / or to check whether all trackers are being considered (e.g., in the network model).

[0188] In a further embodiment, the network or cluster head sends information about all tracker IDs that are currently being considered by the network model or application and / or are part of the cluster, optionally together with information about when the tracker ID was last seen / reported. Each tracker determines, based on this information, whether it needs to report the tracker ID (again). This determination is further based on a preconfigured time limit or number of cycles and / or the (maximum) change / variation in signal strength and / or the (maximum) range / position change within which the tracker ID does not need to be reported again.

[0189] The network 20 passes the received unique ID and the associated metadata as inputs to the network-side model (step S312). The network-side model 202 uses this data in step S314 to calculate an update (LU) of the current estimated value (approximation) of the location for each tracker (e.g., of the tracker group 10 of the asset) and updates the tracker location database.

[0190] Optionally, network 20 also passes, for example, if it is up to network-side model 202 to decrypt them, a protected, e.g., encrypted, unique ID and associated metadata to network-side model 202.

[0191] Network-side model 202 uses various techniques to estimate the location of each tracker in step S314 based on (partial) location data stored at a previous time step and the received unique IDs newly reported from each tracker. For example, if a tracker has a well-known location (e.g., by having GNSS hardware or by a well-characterized location calculated by network-side model 202 at a previous model time step or configured by an installer), the tracker is marked as an anchor point tracker or anchor node. Then, any tracker whose unique ID is received by an anchor point tracker is labeled as being located within a radius given by the D2D tracking range of the associated transmission.

[0192] Optionally, data received from the associated peer tracker of the same transmission is searched by the network-side model to identify matching unique ID transmissions from the same conversation. This provides additional information about the true range of the trackers during a transmission event. For example, if two trackers are using different transmission powers corresponding to different tracking ranges and one can "see" the other while the other cannot "see" the one, the uncertainty about the true range (encoded in network-side model 202) is reduced.

[0193] If the transmission power is variable, the true tracking range is calculated by the ratio between the (known) transmission power used and the (measured) received power received by the peer. For this purpose, the trackers append data indicating their used transmission power to each transmission and / or the receivers include data indicating their received signal strength along with the received unique ID reported.

[0194] Any received unique ID reported in step S307 by a tracker 102 that is not an anchor point (i.e., does not have a well-known ground truth location) is used as an additional constraint on the location by virtue of its relationship to the anchor point tracker, other trackers, and / or their associated tracking ranges.

[0195] Optionally, additional features of the contact tracing data are also used by the network-side model 202 to update its location estimate. For example, if two trackers trace each other multiple times during a wake cycle but the tracking ranges have clearly changed, the network-side model 202 infers that the associated trackers are moving (relative to each other). In this case, the network 20 optionally instructs one or both of the trackers to take an action related to the movement (e.g., actively search for the other after a given time period assuming a given estimated speed and that the other is still within range).

[0196] If the contents of the unique ID memory of a tracker are substantially the same over repeated reports, the network-side model 202 infers that the trackers are permanently collocated. This applies to both stationary trackers (e.g., within a storage location) and moving trackers (e.g., attached to items within the same truck).

[0197] As a further option, if available, additional features of the reported metadata are also used by the network-side model 202 to improve its location estimation. Examples include internal sensor data from a tracker (or collocated trackers) indicating movement, changing temperature, changing received signal strength of network transmissions (including network transmissions of different cells within a cellular network), etc. Changes measured by such internal sensors that meet a pre-configured threshold trigger a change in the ID reporting frequency, trigger a change in the tracking range to be changed, 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 trigger the device to enter a provisioning mode.

[0198] By repeatedly performing at each time step at least some of the above additional evaluation options for all available trackers, the network 20 uses the tracking range and the received unique ID to further suppress the uncertainty of the estimated location of the tracker, for example by means of multilateration techniques.

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

[0200] Examples of actions that enable the network - side model to reduce tracker energy consumption include increasing sleep and reducing wake - cycles (this is used when, for example, the network 20 has sufficient knowledge about a given tracker because the given tracker has been tracked in previous time steps by several anchor - point trackers).

[0201] As previously explained, the tracker 102 joins a cluster when commanded by the network 20 because the tracker 102 is out of coverage and only clusters are visible, or for other reasons (for example, when it is known that groups of trackers will be together during expected use, the installer provisions a group of trackers to form a cluster, which has the advantage that they will operate permanently even if the group of trackers moves out of coverage).

[0202] When it is determined in step S305 that the tracker 102 is in cluster mode, the tracker 102 acts as the SyncRef UE1064 of the cluster 106 and broadcasts the synchronization timing or reference signal (SYNC) during each wake - cycle used by the other cluster trackers 1066 of the cluster 106 to orchestrate communication in step S309.

[0203] The cluster trackers 1066 communicate (report) their IDs and metadata to the other cluster members and the received IDs and metadata to the cluster head 1062 in step S310. One of the cluster trackers 1066 also acts as the cluster head (CLH) 1062 for storing the accumulated unique IDs and metadata for the cluster 106 to be reported to the network 20 in step S311 when possible (available). These can be the same or different trackers.

[0204] In one embodiment, first in cluster provisioning, the network 20 (or the installer's UE 40) acts as both the SyncRef UE 1064 and the cluster head 1062. Thereafter, the selection of the role of the SynRef UE 1064 and / or the cluster head 1062 is made by the cluster tracker 1066 of the cluster 106. In the example, this selection is based on at least one of the availability of an external source of accurate timing (e.g., GNSS), the highest remaining battery life and / or the lowest average transmit power for 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 drifts from the network time / clock). In other examples, this selection is also based on the highest predicted "on" life given the status of all cluster trackers 1066, including aspects such as not only the battery charge / capacity / life status but also the status of the energy harvesting function if available (e.g., a tracker with an active solar panel that has already been generating energy for several hours is a good candidate). For this purpose, the cluster tracker 1066 transmits information about their energy-related status to other cluster trackers 1066.

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

[0206] In an example where only one cluster tracker 1066 of cluster 106 has network coverage, this cluster tracker 1066 acts as both a SyncRef UE 1064 and a cluster head 1062. In another example where two or more cluster trackers 1066 have network coverage, the selection is random or based on the nature of the cluster trackers within the coverage such as remaining battery life or other criteria described above. In particular, for the role of the cluster head 1064, the cluster tracker 1066 with the highest remaining battery life (or other capacity such as storage) is selected.

[0207] In one embodiment, the cluster trackers 1066 append data indicating their signal status with respect to the network (e.g., the measured RSSI of the signal received from the gNB) to their metadata that is broadcast to the cluster head 1062 in step S310 to facilitate the above selection.

[0208] In one embodiment, the cluster tracker 1066 that has become or has been determined to become the cluster head 1062 broadcasts this information to the other cluster trackers 1066 within the cluster 106. Another cluster tracker 1066 currently acting as the cluster head 1062 continues to act as the cluster head 1062 or stops acting as the cluster head 1062 based on the information received from the new cluster head 1062. The cluster tracker 1066 that has become or has been determined to become the cluster head 1062 reports its role as the cluster head to the network 20, optionally together with additional information such as energy status information or signal strength information. The network 20 determines which one of the cluster heads 1062 should become the head of the cluster 106, notifies that decision to that cluster head 1062, and / or notifies the other cluster heads 1062 to stop being the cluster head 1062.

[0209] In one embodiment, the roles of both the SyncRef UE 1064 and the cluster head 1062 alternate between the cluster trackers 1066 of the cluster 106 in each wake cycle, for example, based on data communicated during the previous wake cycle or based on a pre-set schedule.

[0210] When an external timing source (e.g., GNSS) is not available, the timing of subsequent wake cycles is provided by the internal clock of the SyncRef UE 1064 during the intermediate sleep cycles. In this case, the wake time of each sleep / wake cycle is defined to be long enough to compensate for the expected clock drift of the cluster tracker 1066. For example, in a cluster tracker 1066 where the worst-case clock drift is + / -1 s per day, for a 6 h sleep cycle, a wake cycle of 0.5 s plus one transmission time ensures that the wake cycles of the two worst-performing cluster trackers 1066 overlap by at least one transmission time (however, in practice the wake cycle may be longer). This requires the configuration of relevant parameters (e.g., clock drift) for the SyncRef UE 1064 by, for example, the network 20. Such configuration is policy-based.

[0211] Within each wake cycle, the cluster trackers 1066 of the cluster 106 wake up and transmit their IDs while listening for any received IDs, similar to step S307 in the stand-alone mode at step S310. In addition to the IDs, the cluster trackers 1066 communicate metadata, for example, including their remaining battery life (optionally, this metadata is communicated only in a part of the wake cycle). Such metadata can be used to assign the role of the cluster head 1062 to one of the cluster trackers 1066 within the cluster 106.

[0212] As indicated above, the role of the cluster head 1062 alternates after each wake cycle or less frequently as needed. The cluster head 1062 is initially the same cluster tracker as the SyncRef UE 1064 during the first wake cycle. In subsequent wake cycles, the cluster trackers 1066 inform the network 20 via metadata of their availability and / or suitability for the role of the cluster head (e.g., due to high remaining battery life), or alternatively, the current cluster head 1062 makes this determination.

[0213] If the intended next cluster head is selected by the current cluster head 1062 during a wake cycle, and and only if a positive response confirming the role change is received, the role alternates in the next wake cycle. The selection is based on information collected and shared by potential cluster head candidates regarding their ability to reach all members within the cluster 106. In this way, it is possible to have a high certainty that there is always exactly one cluster head 1062.

[0214] In some scenarios, some of the cluster trackers 1066 are never selected as the cluster head 1062. However, the above procedure at least enables some alternation or sharing of roles within the cluster 106.

[0215] In an embodiment, the resource blocks for out-of-coverage D2D cluster transmissions are selected from a default set that is reserved in the standard (similar to the semi-persistent scheduling of mode 3 or 4 out-of-coverage D2D previously referenced).

[0216] The communication of the unique IDs received by the tracker in steps S307 and S310 within each wake cycle is achieved by transferring to network 20 or cluster head 1062 a list of the received unique IDs, each labeled with a respective timestamp and their own metadata, and the list of received unique IDs and timestamps are stored together with the metadata from each tracker. Optionally, in scenarios where an out-of-coverage state is frequently expected for cluster 106, the IDs to be stored are stored not only by cluster head 1062 but also by all cluster trackers 1066 of cluster 106. This increases the likelihood that the IDs will be received by network 20 when cluster tracker 1066 moves alone.

[0217] Optionally, all cluster trackers 1066 (or at least SyncRef UE1064 and cluster head 1062) of cluster 106 are commanded (e.g., by network 20 or installer's UE40) to wake up by default at regular intervals (e.g., once a day or at longer intervals) and use their maximum D2D tracking range to transmit their ID and metadata reports. This option is advantageous for finding any "lost" cluster trackers 1066 that have exited their cluster 106's tracking range and enabling out-of-coverage provisioning of new trackers. Thus, such new or lost trackers can find cluster head 1062 with a higher probability and (re)join their cluster 106.

[0218] When in coverage, the cluster head reports to network 20 the accumulated unique IDs, timestamps, and metadata in step S311. Network side model 202 uses the information from cluster head 1062 to update its location estimate, as in the stand-alone mode case.

[0219] In one embodiment, the network-side model 202 further determines whether it is advantageous to maintain the cluster 106, break the cluster 106, or modify the tracking range or sleep / wake cycle, as in the stand-alone mode (e.g., step S313).

[0220] In addition, in an embodiment, such a decision is made locally by the cluster head 1062 based on locally stored policies, or is deployed by the network 20, and the relevant new parameters (e.g., changed tracking range, role of the SyncRef UE, sleep / wake cycle, etc.) are communicated to the cluster tracker 1066 and / or the SyncRef UE 1064 in step S308.

[0221] For example, if the cluster tracker 1066 is using high transmission power to exchange reports and / or the cluster head 1062 or the SyncRef UE 1064 is transmitting with excessive power, the cluster head 1062 is configured to determine that it is advantageous to split the cluster 106 to form new clusters, in which case both clusters may have lower transmission power (i.e., shorter tracking range). This decision is based on the transmission power required for the signal of the SyncRef UE to reach all the cluster trackers 1066 of the cluster 106. In such a case, the cluster head 1062 is configured to communicate to one of the cluster trackers 1066 that it is required to act as the cluster head and the SyncRef UE for the new cluster during subsequent wake cycles. The selection of this cluster tracker 1066 is based on at least one of the low received signal strength of the candidate cluster tracker (meaning a large distance from the existing cluster head 1062), battery life, and other resources. The new cluster then starts itself and operates as described above.

[0222] In the second example, the cluster head extends the sleep cycle based on little or no change in cluster membership and / or low mobility of the entire cluster 106. For example, this is done when the cluster 106 has reached its maximum size (e.g., so that messages do not become too long). This decision is based on the number of cluster trackers 1066 within the cluster 106.

[0223] (As described above) If a modification is required, the network 20 sends the desired power and timing parameters to the cluster head 1062, or in the case of locally applied changes, the cluster head 1062 sends the relevant new parameters to the cluster members during a subsequent wake cycle, and the settings are applied during a subsequent or later wake cycle.

[0224] In one embodiment, when within coverage, instead of reporting the unique ID accumulated in step S311, the cluster head 1062 sends the difference in the accumulated unique ID compared to the previous wake period (e.g., IDs that have disappeared and / or new IDs) to reduce communication overhead.

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

[0226] Thresholds for such decisions are either hard-coded in the tracker or subject to policies deployed to the tracker via the network 20.

[0227] As an example, such a policy defines that the D2D tracking range is reduced by reducing the D2D transmission power required by the tracker, and that this is done when, for example, the tracker receives more ID transmissions from the peer tracker than are required for proper location estimation.

[0228] As another example, when network 20 identifies that a group of trackers are permanently collocated and / or indicates or estimates that the data of the network-side model is unlikely to change (e.g., due to no relative movement of the trackers) before the next wake cycle, for example, one remaining tracker reports its contact tracing history (list of received IDs) as before, but all other trackers are instructed to suspend uplink communication to network 20, thereby forming a dynamic cluster. This decision may optionally also be made by the tracker itself based on receiving the same unique ID over several wake cycles (which, as explained previously, indicates a static state). The tracking range of cluster 106 is calculated by network 20 (or proposed by cluster head 1062) and communicated to cluster tracker 1066. The sleep / wake cycle remains unchanged, or if the same group of trackers remains collocated for a long time, the sleep cycle is extended as the risk of tracker loss is low. This enables power savings by collectively reducing uplink transmissions without the tracker explicitly entering the cluster mode (which requires additional resources as SyncRef UE1064 needs to broadcast synchronization signals).

[0229] As a further example, a dynamic selection of which tracker acts as SyncRef UE 1064 and / or cluster head 1062 is made for an existing cluster 106. This selection is made either alone by the cluster tracker 1066 of cluster 106 based on a deployed policy, or by the network 20 based on an existing report by the cluster tracker 1066. Alternatively, this selection is based on at least one of the mutual location of the cluster trackers 1066 of cluster 106, the location of cluster 106 relative to the associated gNB of network 20, and the coverage status of cluster 106. For example, if the cluster tracker 1066 is known to be located at the center of cluster 106, it can reach all other cluster trackers 1066 within that cluster 106 with lower transmit power (and thus less energy consumption). Therefore, it is related to selecting the most suitable cluster tracker.

[0230] In cluster mode, such policy-based optimization is also initiated by the cluster head 1062. In this case, in addition to the metadata that is usually appended to the report transmissions by the cluster members, the cluster tracker 1066 also appends data indicating their signal strength (e.g., RSSI) to the network. The cluster head 1062 uses this data, which adds the reception strength of the in-cluster transmissions (as a mutual location indicator), as an input to the determination in the same way as the network 20 as described above.

[0231] As an example, the cluster head 1062 causes all cluster trackers 1066 to transmit a synchronization reference signal, and then selects the SyncRef UE 1064 or the cluster tracker most suitable to act as a new cluster head in subsequent wake cycles by broadcasting the received measured power of the received synchronization reference signal for each. Next, the cluster head 1062 selects one cluster tracker 1066 whose synchronization reference signal is received by all other cluster trackers at best (i.e., in the case of a cluster tracker within the cluster that receives the synchronization reference signal from a given cluster tracker with the lowest received power, the received signal strength is the highest).

[0232] In one embodiment, the selection of the most suitable tracker acting as the cluster head 1062 or the SyncRef UE 1064 is also based on, or exclusively based on, the energy cost of sending / receiving messages with the network 20 (e.g., with the nearest gNB of the network 20). This is relevant when the cluster 106 is within partial coverage. For example, if the SyncRef UE 1064 loses connectivity with the network 20 (e.g., because it moves away from the (assigned) gNB), in some scenarios, the cluster trackers 1066 on the edge of the cluster 106 remain within coverage. As previously explained, it is advantageous for these cluster trackers 1066 to assume the role of the SyncRef UE 1064 and / or the cluster head 1062. This is advantageous because it allows the cluster 106 to continue to have network contact through the cluster head 1062. However, if this results in a high transmit power requirement throughout the cluster 106, the cluster head 1062 attempts to reduce this in-cluster transmit power (i.e., the cluster range).

[0233] In one embodiment, the cluster head 1062 determines to select a tracker (e.g., cluster tracker 1066, stand-alone tracker 102, or isolated tracker 104) that should act as the cluster head 1062 and / or SyncRef UE 1064 having both network coverage and the lowest average transmit power to the remaining members of the cluster 106. This determination is based on the received signal strength of the received synchronization reference signal. A tracker that receives the synchronization reference signal at a high power selects a lower transmit power, and a tracker that receives the synchronization reference signal at a low power selects a higher transmit power.

[0234] As another option, the cluster head 1061 determines to split the cluster 106 into two or more clusters (as a result, for example, at least one in-coverage cluster and at least one out-of-coverage cluster are created).

[0235] The above determination is based on a policy deployed by the network and balancing power usage against the risk of tracker or cluster loss.

[0236] Examples of actions that enable the network-side model 202 to (on average) increase location certainty include expanding the D2D tracking range (this is done for a particular tracker that is thought to be close to a second tracker that is either overall or out-of-coverage or has few resources) (in cluster mode, the cluster head 1061 also initiates this optimization), reducing the sleep cycle and / or increasing the wake cycle (more measurements can be made and the risk of tracker loss during the sleep period due to tracker movement is low) (in cluster mode, the cluster head 1061 also initiates this optimization), breaking the cluster, and controlling the tracker to return to (pure) stand-alone mode, including at least one of them.

[0237] Accordingly, the network-side model is configured to optimize the tracking system for low power usage while only enhancing location accuracy for those trackers when needed.

[0238] In an embodiment, the updated settings and configurations used to implement the optimized tracking system are (securely) communicated by the network 20 to the trackers. To achieve this, the network 20 (i.e., its specific elements / functions) has the authority to make these updates.

[0239] In an embodiment, in addition to the above optimization, the network-side model 202 is configured to command a group of trackers (e.g., cluster tracker 1066, stand-alone tracker 102, or isolated tracker 104) to enter the cluster mode in some scenarios, as described below. The trackers also enter the cluster mode on their own based on a policy deployed by the network to the trackers indicating the relevant conditions / situations.

[0240] The advantage of the cluster mode is that the cluster mode operates in an out-of-coverage state. Therefore, the network-side model 202 bases the decision mainly on whether signal loss can occur or is expected for a given tracker or group of trackers. This is estimated, for example, from their relative movement or position near the cell boundary or from their reported network RSSI or other values. The tracker enters the cluster mode on its own, for example, when the RSSI value drops below a threshold. Alternatively, this decision is made locally by the group of trackers in response to a policy deployed to the group of trackers via the network 20. This is especially true during the provisioning step where details indicating a high likelihood of tracker mobility are provided, for example, by the installer's UE40 (described herein in relation to the cluster provisioning mode). When in the cluster mode, the tracker attempts to join any nearby cluster 106 as described herein in relation to out-of-coverage provisioning. If the tracker successfully joins the cluster 106, the cluster head 1061 uses the RSSI data appended to the metadata of the cluster trackers between the network 20 and each cluster tracker 1066 of the cluster 106 to determine whether to remain in the cluster mode or break the cluster 106 in each wake cycle.

[0241] A second reason to enter the cluster mode is that the known or expected future location of the tracker falls within the range of one or more isolated trackers 104 that are out of coverage, and as a result, having the SyncRef UE signal at that location enables the network 20 to discover one or more isolated trackers 104 that are out of coverage. This applies when the tracker is at the cell boundary or when the tracker is moving along a predictable or known trajectory (e.g., attached to a vehicle whose route plan is known and reported as part of the metadata).

[0242] A third reason for entering the cluster mode is that the cluster mode potentially enables energy savings by minimizing long - distance transmissions from cluster members (as described above). This decision is made locally by the network - side model centrally, or by any cluster head 1061 or tracker, based on the content of its received ID and its coverage status with respect to the network 20.

[0243] In one embodiment, when one or more trackers determine that they should enter the cluster mode, the network - side model 202 commands those trackers to enter the cluster mode via the network 20, and the network 20 is first configured to act as the cluster head 1062 and SyncRef UE 1064 (in this case, the synchronization reference signal is the normal synchronization signal of the network and not the sidelink / D2D synchronization signal used by the SyncRef UE 1064 when in an out - of - coverage state). In that case, the roles of the SyncRef UE and the cluster head are then shared among the members of the cluster 106 according to at least one of battery life, other available resources, and (optionally) mutual location, as previously described herein and as will be described later.

[0244] The trigger for switching from the synchronization reference signal provided by the network to a locally (i.e., by SyncRef UE1064) generated synchronization reference signal is initiated immediately (i.e., during the second wake cycle when network 20 was providing the synchronization reference signal during the first wake cycle), or when any one of the cluster (head) moves out of coverage (this is advantageous by waiting until the "risk" of loss of coverage is detected, which helps maintain power in the tracker by not requiring SyncRef UE1064 until the last minute, but without a locally defined SyncRef UE1064, if the trackers all go out of coverage simultaneously, it results in an increased risk of loss of synchronization for the entire cluster 106).

[0245] The decision between the two above options is made either by network 20 or by any one of the cluster trackers 1066 of cluster 106. For example, either the network - side model 202 or any individual cluster tracker 1066 of cluster 106 starts the switch to the locally generated synchronization reference signal in a subsequent wake cycle, e.g., by setting a suitable logical flag. This enables the individual trackers to "disconnect" from network control in a safe way (i.e., without the risk of loss for the entire cluster 106 if all trackers suddenly move out of coverage).

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

[0247] Returning to the main use phase procedure of FIG. 3, at step S304, when the tracker determines that it is outside the coverage area of network 20, at step S306, it checks whether it can start the cluster mode (e.g., based on the above criteria) or needs to remain isolated (ISO).

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

[0249] In the latter case or when step 306 is skipped, the out-of-coverage tracker 102 determines that it is an isolated tracker (ITR) if it does not receive another tracker ID at step S306 during the wake cycle. Then, the isolated tracker (ITR) attempts to contact the SyncRef UE 1064 of network 20 or a nearby cluster at step S315 (CNT). When network contact is established, the isolated tracker 104 returns to the provisioning phase (PP) at step S316 and retries provisioning as described above with respect to FIG. 2.

[0250] However, if such an isolated tracker 104 determines that it is (again) within coverage, the procedure branches to step S305 or S307 and the isolated tracker 104 is set to the stand-alone mode.

[0251] FIG. 4 schematically shows a flowchart of the sub-procedures of the provisioning phase (steps S401 to S416) and the main use phase (steps S421 to S435) according to each embodiment, executed by the processing unit of the tracker (TR). Note that the functions and parameters described in relation to steps S401 to S435 include all relevant and / or applicable options and examples described above in relation to FIGS. 2 and 3.

[0252] In step S401, when the tracker is turned on for the first time and enters the provisioning mode, the initial provisioning phase (I-PP) is started.

[0253] In step S402, the tracker attempts to contact the network via an existing protocol and / or attempts to find other nearby trackers within the cluster.

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

[0255] If the tracker determines in step S404 that no nearby cluster has been found, the procedure branches to step S406 and the tracker communicates its unique ID (and optional metadata) to the network (NW).

[0256] Then, in step S407, the tracker waits until it receives provisioning data (PD) from the network that includes a nearby cluster (if available).

[0257] In subsequent step S408, the tracker starts a contact tracing broadcast (CT-BC) using the data supplied by the network.

[0258] In optional step S409, the network instructs the tracker to immediately join any suitable cluster.

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

[0260] Next, 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 / W-T) from the cluster head in step S412.

[0261] In step S413, the tracker communicates its unique ID to the cluster head.

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

[0263] Otherwise, if the tracker determines in step S405 that no nearby cluster has been found, the procedure branches to step S415, and the tracker determines whether it requires manual provisioning (MP) by an operator (e.g., via the installer's UE), or that it cannot be provisioned and retries the provisioning stage at defined intervals (or after a detected event such as movement) (RP).

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

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

[0266] In step S422, the tracker enters the wake state during the wake cycle according to the provisioned sleep / wake timing that defines a specific sleep cycle and wake cycle, and the tracker attempts to synchronize (SYNC) with the network or the determined local cluster.

[0267] Next, in step S423, the tracker determines whether it is within the coverage (IC) of the network.

[0268] If it is within the coverage, the procedure branches to step S424, where the tracker determines whether to enter the cluster mode (CLM) or the stand-alone mode (SAM) based on the criteria and options described above in relation to FIG. 3.

[0269] If the tracker selects the stand-alone mode in step S424, the procedure branches to step S426, where the tracker broadcasts (TX) its unique ID (using the local area protocol, e.g., via the local area protocol) and listens (RX) for the received ID and associated metadata.

[0270] Then, according to a pre-set schedule or network requirements, the tracker reports (REP) its received ID and related metadata to the network in step S427, and as a result, the network-side model of the network can update its estimated value of the location of all trackers with the newly received information from the tracker. Optionally, this update is confirmed to the tracker in step S428 (UD L-EST).

[0271] Based on the location estimate generated by the network-side model, the tracker optionally receives from the network in step S429 a request to modify (MOD) its tracking range (TR) and / or update (UF) its frequency.

[0272] Otherwise, if the tracker selects the cluster mode in step S424, the procedure branches to step S430, where the tracker first operates as both a cluster head (CLH) and a SyncRef UE (SR-UE), and the roles of the cluster head and SyncRef UE are distributed among the cluster members in subsequent wake cycles to optimize energy usage.

[0273] In step S431, the tracker and other cluster members continue to locally contact trace (LOC CT) by attempting to receive an ID from other trackers.

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

[0275] When within the network range, the tracker acting in its initial role as the cluster head (or newly selected cluster head (CLH) and / or any other tracker required by the network) reports the accumulated ID history (IDH) in step S433.

[0276] Common step S435 follows steps S429 and S433 above, where the tracker location estimate is updated by the network-side model (the reception is optionally confirmed to the tracker) and reported to a suitable downstream application as required.

[0277] Otherwise, if the tracker determines in step S423 that it is out of coverage, the procedure branches to step S425, where the tracker determines whether it enters the cluster mode (CLM) or is an isolated tracker (ISO) based on the criteria and options described above in connection with FIG. 3, for example.

[0278] If the tracker selects the cluster mode in step S425, the procedure branches to step S430 and continues there.

[0279] Otherwise, if the tracker determines in step S425 that it is an isolated tracker, the tracker attempts to re - establish contact with the network (NW) or attempt to join a cluster (CL) as described above in connection with FIG. 3, for example, in step S434.

[0280] FIG. 5 schematically shows an example of an asset tracking system having a stand - alone mode cluster and a dynamic cluster according to an embodiment.

[0281] As shown in the upper part of FIG. 5, numbers 1, 2, and 3 of the asset tracker 102 are collocated within the D2D tracking range (e.g., PC5 operating range) 502 having a contact tracing range 52. Number 4 of the asset tracker 102 is outside the D2D tracking range 502 but still within the network coverage (e.g., Uu interface to the gNB).

[0282] In step S501, the network (e.g., the network - side model) determines the location estimation values L1, L2, and L3 of the locations numbered 1 to 3 of the asset's tracker 102 based on their broadcast IDs 1 to 3 and the metadata received at the gNB. However, since the asset's tracker number 4 is outside the D2D tracking range 52, it operates in the stand - alone mode and needs to report its ID via a separate transmission. On the other hand, the asset's tracker number 1 acting as the cluster head can report the accumulated IDs of the asset's trackers numbered 1 to 3.

[0283] Next, in step S502, based on the received metadata (as described above in relation to FIG. 3, for example), the network or the cluster head calculates a new dynamic cluster with an increased ranging power for contact tracing. In step S503, it signals the increased ranging power to the cluster, and as a result, an extended range 54 for D2D contact tracing is temporarily provided, and the asset's tracker number 4 of the asset's tracker 102 is now located within the extended contact tracing range 54. As a result, assuming that the asset's tracker number 1 of the asset's tracker 102 acts as the cluster head, number 1 receives the IDs from all other asset's trackers (i.e., numbers 2 to 4) and can report all the IDs without the asset's tracker number 4 having to report separately.

[0284] Figure 6 schematically shows a positioning system for an asset tracker according to one embodiment, implemented alone or in combination with other embodiments. In this embodiment, it is necessary to determine the position of the asset tracker 102. For this purpose, the asset tracker 102 transmits a message A (e.g., a broadcast message, a sounding reference signal, or a measurement report) at time TA with transmission power Tx_A using frequency FA and signal modulation / type MA, for example, via a sidelink / Uu. Thereby, the message includes an ID and, optionally, information about the transmission power Tx_A (or other energy indicators indicating the energy of the transmitted signal), information about the used frequency FA, information about the used signal modulation / type MA, information about which codebook is used, finally the signal strength of the received signal (e.g., RSRP), the time difference or other measurement information between the last received signal and the last transmitted signal, timing advance, location information, tag observation report information, and / or information about nearby gNB / UE / asset trackers 601(_1..N) found (e.g., the cell ID of a nearby base station or the ID received in a message from a nearby UE / asset tracker), and other information provided by the asset tracker 102. The signal characteristics (e.g., transmission power Tx_A, frequency FA, modulation MA) and / or timing (e.g., time TA) used to send message A are based on a previous configuration provided, for example, by the network or a nearby UE / asset tracker (e.g., a cluster head). One or more nearby UE / asset trackers / gNBs 601(_1..K) receive message A and determine the signal strength and / or angle of arrival of the received message A. This information is used to determine the distance or (relative) position of the asset tracker 102. As shown in Figure 6, based on the signal propagation characteristics of the signal used to send message A, the gNB / UE / asset trackers 601(_1..K) are located within a range r1 (indicated by the inner circle).The nearby gNB / UE / asset tracker 601(_1..K) that received Message A sends Message N to the network (e.g., towards the location service) or to a device (e.g., cluster head, anchor node) capable of performing the location service, reporting that it received Message A from the asset tracker 102. Thereby, Message N includes the information received from the asset tracker 102 and / or the information determined based on the fact that it received 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) alternatively or additionally sends Message X indicating that it received Message A to the asset tracker 102. Message X includes information about the gNB / UE / asset tracker 601(_1..K) that received Message A, such as the identifier of the gNB / UE / asset tracker 601(_1..K), the signal strength of the received Message A (e.g., RSRP), the time difference or other measurement information between the received Message A and the sent Message X, location information related to the asset tracker 102 or the gNB / UE / asset tracker 601(_1..K) that sent Message X, tag observation report information, or other information discovered about the nearby gNB / UE / asset tracker.Based on receiving one or more messages X from a nearby gNB / UE / asset tracker 601(_1..K), the information received in message X, and / or configuration information (e.g., a pre-configured schedule for sending the message, and in some cases, the transmission power to be used and / or the policy / criteria / conditions when sending these messages (e.g., when the RSRP reported in message X is below / above a configured threshold or when the number of message X exceeds / falls below a certain threshold)), the asset tracker 102 transmits an additional message B at time T_B with transmission power Tx_B using frequency F_B and signal modulation / type M_B (in some cases, having a similar or the same field / payload or being exactly the same as message A). Thereby, the transmission power Tx_B is different from the transmission power Tx-A, the frequency F_B is different from the frequency F_A, and / or the signal modulation / type M_B is different from the signal modulation / type M_A. Assuming that message B is sent with different characteristics, such as lower transmission power or higher frequency, or using a different codebook, it also affects the signal characteristics of message B. Thus, message B is received by additional or fewer nearby gNB / UE / asset trackers 601(_1..M). As shown in FIG. 6, based on the signal propagation characteristics of the signal used to transmit message A, the gNB / UE / asset trackers 601(_1..M) are located within the range r2 (indicated by the dotted line). The gNB / UE / asset tracker 601 that receives message B transmits a message O (having a similar or the same field / payload as message N) indicating that it has received message B from the asset tracker 102 and transmits a message Y (having the same or a similar field / payload as message X) to the asset tracker 102. Based on the messages N and O received from the gNB / UE / asset trackers 601 that have received message A and / or message B, the network (e.g., the location management function) or a device supporting the location service determines / estimates the location of the asset tracker 102.For this purpose, the network or device uses the fact that message A was received but message B was not received or message B was received but message A was not received by a certain gNB / UE / asset tracker to include / exclude areas in which the asset tracker 102 can be present (e.g., when distance / angle / location estimates are not accurate enough on their own and there are multiple potential locations if information is provided, in which case one or more potential locations can be excluded / included by using information about which areas the asset tracker is present in and which areas it is not present in). Additionally or alternatively, the asset tracker 102 uses messages X and Y received from nearby gNB / UE / asset trackers 601 to determine its own location, and the asset tracker 102 uses its location when sending further messages to the network and / or to change its configuration (e.g., transmit at lower power to reduce the contact tracing range). Note that messages A and B do not have to be just two messages. Messages A and B are part of a series of messages that may each have different signal characteristics (such as using different transmit powers or different codebooks) to more accurately estimate the location of the asset tracker 102. In the example shown in Figure 6 where r2 is greater than r1, the fact that message A was received by gNB / UE / asset tracker 601_1 and message B was received by gNB / UE / asset tracker 601_4 is used by the location service to determine that the asset tracker 102 is located between 601_1 and 601_4 but closer to 601_1 than 601_4.Also, the fact that message B was received by the gNB / UE / asset tracker 601_4 but not by 601_6 is used by the location service to determine that the asset tracker 102 is not located within the range r2' of 601_6, where r2' is the same as or similar to r2 with a certain uncertainty margin (e.g., due to signal fluctuations). Thus, the area indicated by the dashed blue circle with range r2' is used to exclude the potential location of the asset tracker 102. Assuming that the signal range varies given the propagation characteristics of the environment, the calculation / estimation of ranges r1, r2, r2' needs to be performed with a certain error margin. Additionally or alternatively, the asset tracker 102 or the gNB / UE / asset tracker 601(_1..N) sends a series of messages to increase the reliability of the range determination and / or gain further insight into the fluctuations. Additionally or alternatively, the distance and / or angle information derived from the timing of the messages is used to calculate the range more accurately. Additionally or alternatively, since signal fluctuations have the greatest impact at the edges of the signal range, the gNB / UE / asset tracker 601(_1..N) sends a signal / message with the same signal characteristics to the asset tracker 102 (e.g., resends the same message A or B it received) to check whether the asset tracker 102 can receive the signal / message with sufficient quality / signal strength to confirm whether the asset tracker 102 is at or relatively close to the edge of the signal range.

[0285] In a variation of an embodiment, the asset tracker 102 sends a series of messages, each message having a set of signal characteristics whose range is expected to be smaller than or equal to (with a certain pre-configured margin) a previous message in order to minimize the number of gNB / UE / asset trackers 601(_1..M) that can receive those messages (e.g., based on theoretical assumptions or measurements received from the device / adapted to the measurements based on a propagation model). This enables the asset tracker 102 and / or the location service to find the nearest gNB / UE / asset tracker near the asset tracker, which enables the asset tracker to change its configuration accordingly (e.g., transmit with less power to reduce the contact tracing range and include / reach at least one of the nearest gNB / UE / asset trackers near the asset tracker). Also, if the location of one or more of the nearest gNB / UE / asset trackers is known (e.g., through GNSS or other means), the location of the asset tracker 102 can be estimated (e.g., by calculating the respective distances / angles between the asset tracker 102 and one or more of the nearest gNB / UE / asset trackers) by using this location information, the content of the message sent by the asset tracker 102, and / or the measurements associated with receiving the message sent by the asset tracker 102 (e.g., arrival time, RSRP, angle of arrival). In a variation of an embodiment, message X includes configuration information (e.g., transmitted power indication or time / frequency to be used) that the asset tracker 102 should use to send message B.

[0286] In a variation of an embodiment, the network reconfigures the gNB / UE / asset tracker 601 (e.g., by sending new policies / configurations to these gNB / UE / asset trackers) based on messages N and / or O that it receives, e.g., adapts the response messages X and Y that those devices send to the asset tracker 102, or the criteria / conditions when those messages are sent.

[0287] In a variant of an embodiment, if the signal carrying message A is not received by the gNB / UE / asset tracker 601(_1..K) within range r1 and / or the signal carrying message B is not received by the gNB / UE / asset tracker 601(_1..M) within range r2, the signal is blocked by an obstacle. The location service or device that performs the location estimation of asset tracker 102 detects this by determining an estimated value of range r1 based on message N (or message X if the location is determined by asset tracker 102 itself) that it receives from one or more gNB / UE / asset trackers 601(_1..K). Similarly, this can be done for range r2 based on message O (or message Y if the location is determined by asset tracker 102 itself) that it receives from one or more gNB / UE / asset trackers 601(_1..M) within range r2. If it is known that the gNB / UE / asset tracker 601 is located within range r1 (respectively r2), but each device is not sending message N, O, X or Y, a flag is set for that gNB / UE / asset tracker 601. Additionally or alternatively, if it is known that the gNB / UE / asset tracker 601 is located within range r1 (respectively r2), and it is preconfigured / requested to send a message indicating whether it has received message A or B, and it sends a message indicating that it has not received message A or B, a flag is set for that gNB / UE / asset tracker 601. The flagged gNB / UE / asset tracker 601 is preconfigured or requested (e.g., by the location service) to send those messages in order to determine which devices (e.g., other gNB / UE / asset trackers or asset tracker 102) can receive the messages (e.g., PRS / SRS signals for distance measurement or ProSe discovery messages).Furthermore, a tracker of a gNB / UE / asset for which such a flag is set is preconfigured or requested to listen for additional messages from the asset tracker 102 or a tracker of another gNB / UE / asset, whereby those devices are requested to send one or more messages to the tracker of the gNB / UE / asset for which the flag is set. This information can be used by a location service or device that performs location estimation to determine which devices (e.g., a tracker of another gNB / UE / asset or the asset tracker 102) receive those messages and thus can identify potential obstacles and / or which signals are blocked and which are not. Additionally or alternatively, a tracker 601 of a gNB / UE / asset for which such a flag is set is preconfigured or requested to perform wireless sensing of the environment to determine any potential nearby obstacles that may have blocked the reception of message A or message B. The information obtained as a result regarding potential obstacles or blocked signals can be used to determine whether the results of the tracker 601 of the gNB / UE / asset for which the flag is set or its measurements should be excluded from the calculations for performing location estimation by the asset tracker 102 and / or to determine that the tracker 601 of the UE / asset should not be cluster read. Additionally or alternatively, the information obtained as a result is used to reconfigure the asset tracker 102 and / or the tracker 601 of the gNB / UE / asset for which the flag is set to change some transmission parameters (e.g., increase signal strength, redirect the antenna, adapt signal modulation), and / or to instruct / request the asset tracker 102 and / or the tracker 601 of the gNB / UE / asset for which the flag is set to relocate itself.

[0288] In other words, a system / method / device for estimating the location of tracker 102 is provided, where tracker 102 is configured / instructed to transmit a first message having a first set of signal transmission characteristics and a second message having a second set of transmission characteristics that differ from the first set in one or more signal transmission characteristics. The first message is received by a first set of trackers 601(_1..K) of the gNB / UE / asset, and the second message is received by a second set of trackers 601(_1..M) of the gNB / UE / asset. The location of tracker 102 is determined based in part on the fact that one or more gNB / UE / asset trackers are in the first set but not in the second set (or in the second set but not in the first set).

[0289] Furthermore, a system / method / device for reconfiguring tracker 102 is provided, where tracker 102 is configured / instructed to transmit a first message having a first set of signal transmission characteristics and a second message having a second set of transmission characteristics that differ from the first set in one or more signal transmission characteristics. The first message is received by a first set of trackers 601(_1..K) of the gNB / UE / asset, and the second message is received by a second set of trackers 601(_1..M) of the gNB / UE / asset. The configuration of tracker 102 (e.g., signal transmission characteristics or contact tracing range) is changed / determined based in part on the fact that one or more gNB / UE / asset trackers are in the first set but not in the second set (or in the second set but not in the first set).

[0290] In one embodiment implemented alone 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 messages A and B (i.e., reflect / transmit by modulating the incoming illumination signal in the case of backscatter communication). 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 signal characteristics (e.g., different transmit powers) for message A that are different from those for message B, and / or a gNB / UE / asset tracker 601(_Y) different from the gNB / UE / asset tracker 601(_X) used to transmit the illumination signal for message A is used to transmit the illumination signal for message B. The signal characteristics for message A are determined according to a (pre-configured) policy or schedule / configuration (provided to each device by a location service such as an LMF), in response to the "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 are determined based on which gNB / UE / asset tracker 601 is close to the asset tracker 102 (e.g., transmitting with such signal strength, frequency, and / or signal type as to enable the reflected / transmitted modulated signal to be received by as many gNB / UE / asset trackers 601 as possible). The illumination signal is sent in the direction in which the asset tracker 102 is expected to be. For this purpose, the gNB / UE / asset tracker 601(_X) or the location service uses an initial estimate of the location of the asset tracker 102 (e.g., based on information provided from an application or via the NEF, or based on historical information such as the previously known location of the asset tracker, e.g., based on previously reported messages).The location service selects the gNB / UE / asset tracker 601(_X) that is closest to the known / estimated location / initial location of the asset tracker 102 in order to transmit a first illumination signal to the asset tracker 102 and enable the reflection / transmission of a signal, modulation signal A, that results from the asset tracker 102 modulating the illumination signal. For this purpose, the location service (or gNB / UE / asset tracker) sends a message containing a request to transmit the first illumination signal to the selected gNB / UE / asset tracker 601(_X). Such a message also includes configuration information (such as signal characteristics to be used), identification information of the asset tracker 102, and / or angle / distance / location information related to the asset tracker 102. The same gNB / UE / asset tracker 601(_X) is also used to transmit a second illumination signal (having different signal characteristics) to the asset tracker 102 in order to enable the asset tracker 102 to transmit message B. Based on which gNB / UE / asset trackers 601(_1..K) received message A, the measurements made by the gNB / UE / asset trackers 601(_1..K) based on the received message A (such as signal strength, angle of arrival), the calculated distance / position estimate of the asset tracker 102 based on message A, and / or measurements related to receiving message A, different gNB / UE / asset trackers 601(_Y) are used to transmit a second illumination signal (optionally having different signal characteristics) to the asset tracker 102. For this purpose, the location service (or gNB / UE / asset tracker) sends a message containing a request to transmit the second illumination signal to the different gNB / UE / asset trackers 601(_Y). Such a message also includes configuration information (such as signal characteristics to be used), identification information of the asset tracker 102, and / or angle / distance / location information related to the asset tracker 102.The signal characteristics for Message B are determined according to a (pre-configured) policy or schedule / configuration (provided to each device by a location service such as LMF), and / or which gNB / UE / asset tracker 601(_1..K) received Message A (i.e., as reported by Message N) and / or based on the initial location estimate of asset tracker 102 (e.g., based on Message A being received by one or more gNB / UE / asset trackers). As a further option, asset tracker 102 measures the arrival time and / or signal strength of the received illumination signal, and includes in a message (e.g., Message B) transmitted to the network and received by one or more nearby gNB / UE / asset trackers 601(_1..M) a value related to the arrival time of the received illumination signal, a value related to the departure time of the reflected / transmitted signal, the signal processing delay (e.g., in microseconds), a measured value of the signal strength of the received illumination signal (e.g., RSRP), an indication of the antenna loss of the antenna of asset tracker 102 (e.g., in dBm, having a value for reception different from that for reflection / transmission), and / or the transmission power (or other energy indicator) of the modulated signal reflected / transmitted by asset tracker 102. The arrival time of the incoming illumination signal at asset tracker 102, the departure time of the reflected / transmitted modulated signal (e.g., constituting Message B), the difference between the arrival time and the departure time, and / or the signal processing delay of asset tracker 102 are used together with other measurements (such as the arrival time, angle of arrival, etc. of the received modulated signal) by gNB / UE / asset tracker 601 that receives the reflected / transmitted modulated signal to calculate one or more distances and the angle between asset tracker 102 and those gNB / UE / asset trackers and / or to calculate / estimate the position of asset tracker 102.Similarly, the signal strength of the received illumination signal, the transmission power (or other energy indicator) of the reflected / transmitted modulation signal, and / or the antenna loss information are used together with other measurements (such as the signal strength of the received modulation signal (e.g., RSRP)) by the gNB / UE / asset tracker 601 that receives the reflected / transmitted modulation signal to calculate one or more distances, the angles between the asset tracker 102 and those gNB / UE / asset trackers, and / or to calculate / estimate the position of the asset tracker 102. Similar to what was mentioned in other embodiments, message A is received by a first set of gNB / UE / asset trackers 601(_1..K) within range r1, and message B is received by a second set of gNB / UE / asset trackers 601(_1..M) within range r2. The asset tracker or location service uses the fact that message A is received by the first set of gNB / UE / asset trackers rather than by the gNB / UE / asset trackers in the second set to include / exclude the area in which the asset tracker 102 can be present.

[0291] In a variant of an embodiment, if the signal carrying message A is not received by the gNB / UE / asset tracker 601(_1..K) within range r1 and / or the signal carrying message B is not received by the gNB / UE / asset tracker 601(_1..M) within range r2, the signal is blocked by an obstacle. The location service or device that performs the location estimation of asset tracker 102 detects this by determining an estimated value of range r1 based on message N (or message X if the location is determined by asset tracker 102 itself) that it receives from one or more gNB / UE / asset trackers 601(_1..K). Similarly, this can be done for range r2 based on message O (or message Y if the location is determined by asset tracker 102 itself) that it receives from one or more gNB / UE / asset trackers 601(_1..M) within range r2. If it is known that the gNB / UE / asset tracker 601 is located within range r1 (r2 respectively), but each device is not sending message N, O, X or Y, then the gNB / UE / asset tracker 601 is flagged. Additionally or alternatively, if it is known that the gNB / UE / asset tracker 601 is located within range r1 (r2 respectively) and it is preconfigured / requested to send a message indicating whether it has received message A or B, and it sends a message indicating that it has not received message A or B, then the gNB / UE / asset tracker 601 is flagged. When backscatter communication is used, the flagged gNB / UE / asset tracker is required to send an illumination signal to asset tracker 102 and determine whether it receives a reflected / transmitted modulated signal (e.g., carrying message A or B), and then the flagged gNB / UE / asset tracker reports this to the location service or device that performs the location estimation of asset tracker 102.Similarly, the trackers 601 of other nearby gNB / UE / assets report whether they received the modulated signals reflected / transmitted from the tracker of the flagged gNB / UE / asset, based on the illumination signals from the tracker of the flagged gNB / UE / asset. This information can be used by a location service or device that performs location estimation to determine which devices (e.g., trackers of other gNB / UE / assets or the tracker 102 of the asset) received their messages and thus can identify potential obstacles and / or which signals are blocked and which are not. The information resulting from the potential obstacles or blocked signals can be used to determine whether the measurements of the tracker 601 of the flagged gNB / UE / asset should be excluded from the calculations for performing the location estimation of the tracker 102 of the asset and / or to determine that the tracker 601 of the UE / asset should not be cluster-read. Additionally or alternatively, the resulting information is used to reconfigure the tracker 102 of the asset and / or the tracker 601 of the flagged gNB / UE / asset to change some transmission parameters (e.g., increase signal strength, redirect the antenna, adapt signal modulation), and / or to instruct / request the tracker 102 of the asset and / or the tracker 601 of the flagged gNB / UE / asset to relocate itself.

[0292] In other words, a system / method / device for location estimation of tracker 102 is provided, where tracker 102 is adapted to receive a first illumination signal (i.e., from tracker 601 of a first gNB / UE / asset) to enable it to transmit / send a first message having a first set of signal transmission characteristics, and to receive a second illumination signal (i.e., from tracker 601 of a second gNB / UE / asset that is the same as tracker 601 of the first gNB / UE / asset) to enable it to transmit / send a second message having a second set of transmission characteristics that is different from the first set. The first message is received by a first set of trackers 601(_1..K) of the gNB / UE / asset, the second message is received by a second set of trackers 601(_1..M) of the gNB / UE / asset, and the location of tracker 102 is determined based on which trackers 601(_1..K) of the gNB / UE / asset received the first message and / or which trackers 601(_1..M) of the gNB / UE / asset received the second message, based on measurements performed by the first and / or second sets of trackers of the gNB / UE / asset upon receiving the first message or the second message respectively, and / or based on the fact that one or more trackers of the gNB / UE / asset are in the first set but not in the second set (or in the second set but not in the first set).

[0293] The second set of transmission characteristics is configured / ordered to be different from the first set of transmission characteristics based on which trackers 601(_1..K) of the gNB / UE / asset received the first message, based on measurements performed by trackers 601(_1..K) of the gNB / UE / asset upon receiving the first message, and / or based on the calculated distance / location estimate of tracker 102 of the asset based on the first message.

[0294] The system / method / device is adapted to select a second gNB / UE / asset tracker 601 differently from the first gNB / UE / asset tracker 601 and / or to cause the second gNB / UE / asset tracker 601 to use a set of signal transmission characteristics different from the set of signal transmission characteristics used to transmit a first illumination signal, in order to transmit a second illumination signal, whereby the set of signal transmission characteristics for the second gNB / UE / asset tracker 601 and / or the second illumination signal is selected / adapted based on which gNB / UE / asset tracker 601(_1..K) received a first message, based on measurements performed by the gNB / UE / asset tracker 601(_1..K) based on receiving the first message, and / or based on the calculated distance / position estimate of the asset tracker 102 based on the first message.

[0295] Furthermore, a system / method / device for reconfiguring the tracker 102 is provided, the tracker 102 being adapted to receive a first illumination signal in order to be able to transmit / send a first message having a first set of signal transmission characteristics and to receive a second illumination signal in order to be able to transmit / send a second message having a second set of transmission characteristics different from the first set, the first message being received by a first set of gNB / UE / asset trackers 601(_1..K), the second message being received by a second set of gNB / UE / asset trackers 601(_1..M), and the configuration of the tracker 102 (e.g., signal transmission characteristics or contact tracing range) being changed / judged based in part on the fact that one or more gNB / UE / asset trackers are in the first set but not in the second set (or in the second set but not in the first set).

[0296] In summary, an asset tracking system and method have been described that provide mutual contact tracing by a tracker via a low-power local protocol, enabling trackers of low-capability and low-cost assets to be tracked by an electrical communication network or other wireless network while significantly reducing the power demand of the asset trackers. Contacts are reported to the network, and the network can optimize the power usage by the tracker for the location certainty of its current model by reducing the number and / or their transmission power of uplink transmissions or D2D transmissions, and / or by fixed cluster formation or dynamic cluster formation as needed.

[0297] Although the present invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description should be considered to be illustrative or exemplary and not restrictive. The present invention is not limited to the disclosed embodiments. The proposed enhanced asset tracking systems and procedures can be implemented in all types of wireless networks, for example, applied to trackers that communicate using cellular wireless communication standards, particularly the 3rd Generation Partnership Project (3GPP (R)) 5G and New Radio (NR) specifications. 5G wireless communication trackers can be different types of devices, such as mobile phones, smartwatches, 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, low-power medical sensors for health monitoring, medical (emergency) diagnostic and treatment devices for hospital use or first responder use, virtual reality (VR) headsets, and the like.

[0298] ProSe relaying and sidelink communication have been described, but the present invention applies to other types of intermediate nodes capable of forwarding respective messages (e.g., contact reports) received from a (smart) repeater device, a (cellular) gateway UE, an integrated access and backhaul (IAB) node, or other types of relaying devices such as a Wi-Fi mesh app, or other types of tracker devices.

[0299] Furthermore, the present invention can be applied in medical applications or connected healthcare where multiple wireless (e.g., 4G / 5G) connected sensor or actuator nodes participate, in medical applications or connected healthcare where wireless (e.g., 4G / 5G) connected devices, such as video, ultrasound, X-ray, computed tomography (CT) imaging devices, real-time patient sensors, audio or voice or video streaming devices used by medical staff, occasionally consume or generate a continuous data stream at a certain average data rate, in general IoT applications where wireless, mobile or stationary sensor or actuator nodes (e.g., smart city, logistics, farming, etc.) are involved, in emergency services and critical communication applications, in V2X systems, in systems for improved coverage for 5G cellular networks using high frequency (e.g., mmWave) RF, and in any other application areas of 5G communication where relaying is used.

[0300] Other variations to the disclosed embodiments can be understood and achieved by those skilled in the art when practicing the claimed invention, from a consideration of the drawings, the present disclosure, and the appended claims. In the claims, the term "comprising" does not exclude other elements or steps, and the singular does not exclude the plural. The above description has detailed some embodiments of the present invention. However, even though the foregoing may appear as detailed as possible in text, the present invention can be practiced in many ways and thus should be understood not to be limited to the disclosed embodiments. It should be noted that the use of specific terms when describing some features or aspects of the present invention should not be taken to mean that the term is redefined herein so as to limit it to any specific characteristics of the features or aspects of the present invention with which the term is associated.

[0301] Furthermore, when expressions similar to "at least one of A, B, and C, etc." are used, generally, such a structure is intended in the sense that those skilled in the art would understand the expression. For example, a "system having at least one of A, B, and C" includes, without limitation, a system 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. When expressions similar to "at least one of A, B, or C, etc." are used, generally, such a structure is intended in the sense that those skilled in the art would understand the expression. For example, a "system having at least one of A, B, or C" includes, without limitation, a system 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. It will be further understood by those skilled in the art that any substantially disjunctive and / or disjunctive clauses indicating two or more alternative terms, whether in the specification, in the claims, or in the drawings, are intended to contemplate the possibility of including one of those terms, any of those terms, or both terms. For example, the clause "A or B" will be understood to include the possibilities of "A" or "B" or "A and B".

[0302] A single unit or device performs the functions of several items listed in the claims. The mere fact that certain means are listed in mutually different dependent claims does not indicate that a combination of these means cannot be used advantageously.

[0303] The described operations, such as those shown in FIGS. 2 to 4, can each be implemented as program code means of a computer program and / or as dedicated hardware of a commissioning device or a lighting fixture device. The computer program is stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, which is supplied 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 telecommunications systems.

Claims

1. An apparatus for controlling a tracker to provide information about an item and / or tracker to be tracked to a tracker control system via a wireless network, the apparatus comprising: performing local contact tracing of other trackers, providing a contact report derived from the local contact tracing to the tracker control system, the apparatus.

2. The apparatus according to claim 1, wherein the contact report includes identification information of the contacted tracker, the type of the contacted tracker, the detected value of the contacted tracker, the location of the contacted tracker, and / or location information of the contacted tracker.

3. The apparatus according to claim 1 or 2, wherein the local contact tracing is configured to save energy of the trackers of the tracker control system by at least one of combining individual contact reports to reduce the number and range of uplink communications required for any of the trackers, enabling network-controlled or cluster-controlled sleep and / or wake cycles of the trackers, and delegating the task of maintaining network contact to the trackers.

4. The apparatus according to claim 3, adapted to maintain functionality even when outside the coverage of the wireless network by enabling the tracker to be locally provisioned and maintained in such a way as to report information about contacts that occurred with the tracker while it was discoverable at an opportune time and outside the coverage.

5. The apparatus according to any one of claims 1 to 4, adapted to control the contact tracing range and / or sleep and / or wake cycles of the tracker based on at least one of the location and detected movement of the tracker.

6. The apparatus according to any one of claims 1 to 5, adapted to enter a provisioning mode to discover local trackers that are part of a cluster and / or the wireless network.

7. An apparatus for controlling a tracker control system operating via a wireless network, the apparatus comprising: Obtaining information about the item to be tracked by the tracker control system and / or the plurality of trackers, wherein the information is reported by at least one of the plurality of trackers via contact tracing; Controlling at least one of the plurality of trackers to change at least one of the contact tracing range and the sleep and / or wake cycle, and / or to reduce the number of uplink transmissions, and / or to form a cluster of trackers; An apparatus for performing the above.

8. The apparatus according to claim 7, wherein the apparatus comprises a network-side model for changing at least one of the contact tracing range and the sleep and / or wake cycle of the plurality of trackers.

9. The apparatus according to claim 8, wherein the network-side model uses 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 to calculate the known or estimated location-related information of each of the plurality of trackers.

10. The apparatus according to claim 7, 8 or 9, wherein the cluster is discoverable by the tracker or the tracker control system, and the apparatus enables the provisioning of at least one cluster of trackers in such a way that the cluster is configured to report information about the traced contacts that occurred between the trackers of the cluster while outside the coverage of the wireless network.

11. A tracker comprising the apparatus according to any one of claims 1 to 6.

12. The tracker according to claim 11, wherein the tracker provides location information to the tracker control system, and the contact report includes information about contacts with another tracker.

13. A tracker control system comprising a plurality of the trackers according to claim 11 or 12, and a wireless network comprising the device according to any one of claims 7 to 10 within a network device and / or within a cluster head of a cluster of cluster trackers, wherein the tracker control system further comprises a synchronization device for providing a time synchronization reference signal to the cluster trackers within a cluster range.

14. A method of controlling the tracker to provide information about an item and / or a tracker to be tracked to a tracker control system via a wireless network, the method comprising: performing local contact tracing of other trackers; providing a contact report derived from the local contact tracing to the tracker control system; and having.

15. A method of controlling a tracker control system operating via a wireless network, the method comprising: obtaining information about an item to be tracked by the tracker control system and / or a plurality of trackers, the information being reported by at least one of the plurality of trackers via contact tracing; controlling at least one of the plurality of trackers to change at least one of a contact tracing range and a sleep and / or wake cycle, and / or to reduce the number of uplink transmissions, and / or to form a cluster of trackers; and having.

Images