Low-Power and Secure Feature Determination of Tags for Cellular Networks

Abstract

The present invention relates to the determination of characteristics of a communication device 401, including, for example, identification information, type, type of product to which the communication device 401 is attached, location, and sensed values of the communication device 401. In particular, the communication device 401 may be a low-power and low-complexity tag within a cellular communication network having a location identification function that cooperates with other nodes 411 to report the location of the tag to a location information service 441.

Description

Technical Field

[0001] The present invention relates to wireless networks, and in particular, to characteristics of low-power devices in cellular networks such as, but not limited to, networks of the fifth generation (5G) or higher generations, and in particular, to location determination.

Background Art

[0002] In a location information system within a cellular network or infrastructure, multiple types of devices may participate to provide a location identification function. These types can include, for example, tags, powerful mobile user equipment devices (UEs) (such as smartphones, V2X connected vehicles, etc.), or infrastructure devices (such as fixed and / or mobile gNBs, V2X roadside units, etc.). A tag is defined as a device whose location is unknown and which is the target of location identification, and a node can be defined as any device that participates in location identification. Some nodes may function as "anchor nodes" (also referred to as "anchors"), i.e., nodes that do not move, for example (such as fixed infrastructure nodes), or because cellular positioning techniques that enable the cellular network to identify the location of the UE are used, or because the node can identify its own location with high accuracy using a Global Navigation Satellite System (GNSS) (such as the Global Positioning System (GPS)), and thus can function as a participating device whose 2D or 3D location is already known to the location information system with a certain degree of accuracy.

[0003] However, a situation may occur where the tag is outside the coverage (OoC) of the cellular infrastructure. Since nodes such as gNBs within the network infrastructure are mainly used as anchor nodes, this means that for these OoC tags, their positions cannot be estimated with the desired accuracy. Also, in the case of low-power tags, since very low energy consumption and / or a very long (battery) life are required, transmissions and / or measurements by the tag cannot be continuously performed, and wireless reception (Rx) and transmission (Tx) by the tag cannot be carried out 100%. These make communication between such tags and the wireless network infrastructure difficult.

[0004] Furthermore, low-power tags do not transmit as frequently as normal UEs. Therefore, they do not need to be always connected to the network. Instead, they mostly operate in a sleep mode with ultra-low power consumption and wake up only when there is data to transmit (e.g., new measurements by the tag are ready) and / or when the gNB has data to send to the tag in the downlink. Since tags are low-cost and low-complexity, it is important that there is an effective wake-up solution that can adapt to the resource constraints of small tags and is scalable to a large number of tags.

[0005] For privacy reasons, the ID of the tag and the location information associated with the tag should not be disclosed to other tags and / or anchors. Also, only an approved and adequately protected location information service located in the core network, cloud, or other locations on the Internet should be able to perform tag position estimation and share this data with relevant approved stakeholders and / or services, so it is desirable that it not be disclosed to individual infrastructure nodes (e.g., gNB). This is particularly important in the case of a standardized solution where tags from multiple vendors and owners must cooperate with the infrastructure of multiple operators to achieve the common goal of tag localization. It is important to conform to the resource constraints of small tags and obtain a scalable security and / or privacy solution for a large number of tags.

Summary of the Invention

[0006] An object of the present invention is to overcome at least some of the above problems.

[0007] This object is achieved by a communication device according to claim 1, a method according to claim 15, a system according to claim 16, and a computer program product.

[0008] According to a first aspect, a communication device (e.g., a mobile, fixed, or intermittently mobile and fixed UE or tag) in a wireless network in which characteristics of the communication device (e.g., location, ID, device type, and sensed values, etc.) are to be identified is provided. The communication device as a node generates a first secure report message, receives configuration information indirectly or directly from a base station device (e.g., when the communication device is within the coverage of the base station device), and may be configured to transmit the first secure report message, The configuration information includes at least information regarding a time window during which the communication device transmits a first secure report message to a base station device and / or other nodes and receives a secure report message from other nodes, and / or information regarding a frequency resource used by the communication device to transmit a first secure report message to a base station device and / or other nodes and receive a secure report message from other nodes.

[0009] In addition, the configuration information may further include at least information regarding a time window configured for the communication device to harvest energy from an external source (also referred to as an ambient source), and / or information regarding a frequency resource configured for the communication device to harvest energy from an external source (also referred to as an ambient source), and / or energy harvesting related information configured for the communication device to harvest energy from an external source (also referred to as an ambient source).

[0010] Also, the configuration information may further include information regarding a time window during which the communication device wakes up to detect a signal indicating whether the base station and / or other nodes have data to transmit to the communication device and / or have energy to transmit to the communication device, and / or information regarding a frequency resource during which the communication device wakes up to detect a signal indicating whether the base station and / or other nodes have data to transmit to the communication device and / or whether the communication device may harvest energy from an external source (also referred to as an ambient source). The signal may further include at least information regarding a device identifier and / or a device group identifier associated with the communication device and / or a group of communication devices.

[0011] Note that the configuration information may further include at least information regarding a device identifier and / or a device group identifier for activating a communication device and / or a group of communication devices to harvest energy from an external source (also referred to as an ambient source) and / or to transmit a first secure report message and / or to receive a secure report message from another node.

[0012] Also, when the communication device is outside the coverage of the base station device, the configuration information may be received indirectly from the base station device, and it should be noted that such configuration information may be relayed by one or more other devices (nodes) in the network from the base station device.

[0013] The communication device as a node may be a tag, and the characteristics of the tag may be obtained by reading the tag. This characteristic may include the ID of the tag. If the base station to which the ID of the tag is delivered is known, it may be possible to estimate the (approximate) position of the tag. The characteristic may also include a device type indicating the type of the device or the type of the device / product to which the device is attached. When the communication device as a node is a tag, the secure report message of the node or another node may include (or itself may be) a secure tag report message.

[0014] According to a second aspect, a method for identifying characteristics (such as position, ID, and device type, etc.) of a communication device as a node in a wireless network is provided, and the method may include generating a first secure report message, receiving configuration information indirectly or directly from the base station device (for example, when the communication device is within the coverage of the base station device), and transmitting the first secure report message. The configuration information includes at least information regarding a time window during which the communication device transmits a first secure report message to a base station device and / or other nodes and receives a secure report message from other nodes, and / or information regarding a frequency resource used by the communication device to transmit a first secure report message to a base station device and / or other nodes and receive a secure report message from other nodes.

[0015] In addition, the configuration information may further include at least information regarding a time window used by the communication device to harvest energy from an external source (also referred to as an ambient source), and / or information regarding a frequency resource used by the communication device to harvest energy from an external source (also referred to as an ambient source), and / or energy harvesting related information used by the communication device to harvest energy from an external source (also referred to as an ambient source).

[0016] Furthermore, the configuration information may further include a time window during which the communication device wakes up to detect a signal indicating whether the base station and / or other nodes have data to transmit to the communication device and / or have energy to transmit to the communication device, and / or information regarding a frequency resource used by the communication device to detect a signal indicating whether the base station and / or other nodes have data to transmit to the communication device and / or whether the communication device may harvest energy from an external source (also referred to as an ambient source). The signal may further include at least information regarding a device identifier and / or a device group identifier associated with the communication device and / or a device in the group of the communication device.

[0017] Note that the configuration information may further include at least information regarding a device identifier and / or a device group identifier for activating a communication device and / or a group of communication devices to harvest energy from an external source (also referred to as an ambient source) and / or to transmit a first secure report message and / or to receive a secure report message from another node.

[0018] Also, the configuration information may further include at least information regarding the number of repetitions of the repeated transmission of physical packets of the secure report message from the communication device.

[0019] Also, the configuration information may further include at least information regarding data duplication from the communication device.

[0020] According to a third aspect, in a wireless network, a system is provided that includes at least a plurality of communication devices of a first aspect, a plurality of base station devices, and a core network location identification service that determines the location estimation of a target communication device among the plurality of communication devices.

[0021] Finally, according to a fourth aspect, a computer program product is provided that may include code means for generating steps of the method according to the second aspect when executed on a computer device.

[0022] According to a first option that may be combined with any of the first to fourth aspects above, the transmission of the first secure report message may be performed using a frequency resource that depends on an identifier and / or within a time window.

[0023] According to a second option that may be combined with the first option and / or any of the first to fourth aspects above, the communication device receives a secure report message as a second secure report message from one or more other nodes, In response to receiving at least some second secure report messages, generate respective observation reports associated with the reception of the at least some second secure report messages, May be configured to selectively embed the observation report within the first secure report message.

[0024] According to a third option that may be combined with the first or second option and / or any of the first to fourth aspects described above, the communication device When the communication device is located within the coverage of the synchronization source, receives a timing reference from the synchronization signal, When the communication device is not located within the coverage of the synchronization source, may be configured to infer a timing reference from the reception of at least one second secure report message from at least one neighboring node among one or more other nodes.

[0025] According to a fourth option that may be combined with the first to third options and / or any of the first to fourth aspects described above, the communication device May be configured to embed the received configuration information as a configuration data field within the first secure report message.

[0026] According to a fifth option that may be combined with the first to fourth options and / or any of the first to fourth aspects described above, the configuration data field may at least include a predefined target numerical type for controlling, and / or affecting, and / or limiting the size of the first secure report message.

[0027] According to a sixth option that may be combined with any of the first to fifth options and / or any of the first to fourth aspects described above, the communication device It may be configured to control the transmission power for transmitting a first secure report message using a pre - defined transmission control policy determined based on the received configuration information.

[0028] According to a seventh option that may be combined with any of the first to sixth options and / or any of the first to fourth aspects above, the first secure report message may at least include a secure section data field that is an output of an encryption function over a plurality of data items.

[0029] According to an eighth option that may be combined with any of the first to seventh options and / or any of the first to fourth aspects above, the plurality of data items of the secure section data field may at least include a temporary identifier of the communication device.

[0030] According to a ninth option that may be combined with any of the first to eighth options and / or any of the first to fourth aspects above, the communication device embeds a payload within the first secure report message, and may be configured to transmit the first secure report message including the embedded payload, where the payload is an output of a locally - computed encryption function.

[0031] According to a tenth option that may be combined with any of the first to ninth options and / or any of the first to fourth aspects above, selectively embedding an observation report within the first secure report message includes selecting, from among the observation reports, the observation reports that have been transmitted fewer times than a pre - defined threshold and / or selecting, from among the observation reports, newer observation reports and / or selecting, from among the observation reports, observation reports that do not indicate having been transmitted by a node within the coverage of the base station device and / or selecting the observation reports marked or identified as having a high priority, and including the selected observation reports in a first secure report message to be sent, may be included.

[0032] According to an alternative form of a tenth option which may be combined with any of the first to ninth options and / or any of the first to fourth aspects described above, selectively embedding an observation report in a first secure report message is selecting, from among the observation reports, the observation reports transmitted before exceeding a predefined threshold number of times, and / or selecting, from among the observation reports, older observation reports, and preventing the selected observation reports from being embedded in a first secure report message to be sent as part of the first secure report message during a time window, and may include sending the unselected observation reports among the observation reports.

[0033] According to an eleventh option which may be combined with any of the first to tenth options and / or any of the first to fourth aspects described above, the communication device may be configured to automatically extend the time window when there is no available time slot on the transmission frequency channel of the frequency resource within the time window, or when the ratio of the occupied time slots within the time window exceeds a predefined threshold.

[0034] According to a twelfth option which may be combined with any of the first to eleventh options and / or any of the first to fourth aspects described above, the communication device When a communication device is located on a cell boundary that separates a cell within the coverage of a base station device from another cell within the coverage of another base station device, the communication device receives other configuration information from the other base station device, and the other configuration information includes at least information regarding another time window during which the communication device performs transmission and reception, and information regarding another frequency resource used by the communication device for transmission and reception. The communication device may be configured to perform conditional transmission in both the time window and the other time window.

[0035] According to a 13th option that may be combined with any of the 1st to 12th options and / or any of the 1st to 4th aspects described above, a core network location information service receives a secure report message transmitted as a unicast message from a communication device among a plurality of communication devices, or when a base station device among a plurality of base station devices receives a secure report message from a communication device within the coverage of the base station device, directly receives a variation of the secure report message from the base station device, and the variation of the secure report message may be a secure report message embedded in an observation report generated by the base station device, or may correspond to at least one secure element of the secure report message.

[0036] According to a 14th option that may be combined with any of the 1st to 13th options and / or any of the 1st to 4th aspects described above, the core network location information service uses a secure section data field as an input for each received secure report message and / or uses several inputs to compare the output of a cryptographic function with the secure section data field, and accordingly may be configured to perform a cryptographic function calculation by identifying the true ID of the target communication device.

[0037] According to the 15th option, which may be combined with any one of the 1st to 14th options and / or any one of the 1st to 4th aspects described above, the communication device receives configuration information from a base station device and / or other devices using RF backscatter communication and / or may be configured to transmit a first secure report message using RF backscatter communication.

[0038] According to the 16th option, which may be combined with any one of the 1st to 16th options and / or any one of the 1st to 4th aspects described above, the core network location information service may be configured to disclose the collected location information of the communication device to authenticated and authorized external users and / or services.

[0039] According to the 17th option, which may be combined with any one of the 1st to 17th options and / or any one of the 1st to 4th aspects described above, when the communication device is located on a cell boundary separating a cell within the coverage of a base station device from another cell within the coverage of another base station device, the communication device receives other configuration information from the other base station device, and the other configuration information includes at least information regarding other time windows used by the communication device for transmission and reception and information regarding other frequency resources used by the communication device for transmission and reception. The communication device may be configured to perform conditional reception in both the time window and the other time window.

[0040] According to the 18th option, which may be combined with any one of the 1st to 17th options and / or any one of the 1st to 4th aspects described above, the communication device When a communication device is located on a cell boundary that separates a cell within the coverage of a base station device from another cell within the coverage of another base station device, the communication device receives other configuration information from the other base station device, and the other configuration information includes at least information regarding other time windows used for the communication device to perform transmission and reception, and information regarding other frequency resources used by the communication device for transmission and reception. The communication device may be configured to perform conditional transmission in both the time window and the other time window using RF backscatter communication. It may be configured to perform conditional reception in both the time window and the other time window using RF backscatter communication.

[0041] According to a 19th option that may be combined with any one of the 1st to 18th options and / or any one of the above-described 1st to 4th aspects, the communication device may be configured to harvest energy according to configuration information received from the base station device and / or other devices.

[0042] According to a 20th option that may be combined with any one of the 1st to 19th options and / or any one of the above-described 1st to 4th aspects, the communication device When a communication device is located on a cell boundary that separates a cell within the coverage of a base station device from another cell within the coverage of another base station device, the communication device receives other configuration information from the other base station device, and the other configuration information further includes information regarding other time windows used for the communication device to harvest energy from an external source (also referred to as an ambient source), and / or information regarding other frequency resources used for the communication device to harvest energy from an external source (also referred to as an ambient source), and / or other energy harvesting-related information used for the communication device to harvest energy from an external source (also referred to as an ambient source). The communication device may be configured to perform conditional energy harvesting in both the time window and the other time window.

[0043] According to a 21st option that may be combined with any one of the 1st to 20th options and / or any one of the above-mentioned 1st to 4th aspects, the communication device receives configuration information from a base station device and / or other devices, and the configuration information further includes information regarding a time window for the communication device to harvest energy from an external source (also called an ambient source), and / or information regarding a frequency resource for the communication device to harvest energy from an external source (also called an ambient source), and / or energy harvesting-related information for the communication device to harvest energy from an external source (also called an ambient source), and the communication device may be configured to perform conditional energy harvesting during the time window.

[0044] According to a 22nd option that may be combined with any one of the 1st to 21st options and / or any one of the above-mentioned 1st to 4th aspects, the communication device receives configuration information from a base station device and / or other devices, and the configuration information further includes a time window for the communication device to start up and detect a signal indicating whether the base station and / or other nodes have data to transmit to the communication device and / or have energy to transmit to the communication device, and / or information regarding a frequency resource for the communication device to detect a signal indicating whether the base station and / or other nodes have data to transmit to the communication device and / or whether the communication device may harvest energy from an external source (also called an ambient source). The above signal may further include at least information regarding a device identifier and / or a device group identifier associated with the communication device and / or a device group of the communication device, and starts up conditionally during the time window to detect the above signal.

[0045] According to the 23rd option, which may be combined with any one of the 1st to 22nd options and / or any one of the above-mentioned 1st to 4th aspects, the communication device receives configuration information from a base station device and / or other devices, and the configuration information further includes information regarding a device identifier and / or a device group identifier for activating the communication device and / or a group of communication devices to harvest energy from an external source (also called an ambient source), and / or to transmit a first secure report message, and / or to receive a secure report message from other nodes. The communication device may be configured to conditionally activate to harvest energy from an external source (also called an ambient source), and / or to transmit a first secure report message, and / or to receive a secure report message from other nodes.

[0046] According to the 24th option, which may be combined with any one of the 1st to 24th options and / or any one of the above-mentioned 1st to 4th aspects, the base station and / or other access devices transmit one or more collision signals to the communication device at different times, frequencies, and / or spatial positions for the communication device to reflect the backscatter RF signal to transmit a secure report message. receive one or more reflected backscatter RF signals reflected from the communication device, and may be configured to conditionally (partially or completely) combine a plurality of copies of the received, reflected backscatter RF signals to decode the transmitted security report message collectively.

[0047] According to the 25th option, which may be combined with any one of the 1st to 25th options and / or any one of the above-mentioned 1st to 4th aspects, the base station and / or other access devices In addition to, or instead of, the transmission location, receive one or more backscatter RF signals reflected from the communication device at one or more locations, and conditionally (partially or fully) combine the multiple received copies of the reflected backscatter RF signals received at multiple different locations to collectively decode the transmitted secure report message.

[0048] Note that each of the above devices may be implemented based on individual hardware components, integrated chips, or individual hardware circuits having a chip module configuration, or may be stored in a memory, written on a computer-readable medium, or implemented based on a signal processing device or chip controlled by software routines or programs downloaded from a network such as the Internet.

[0049] It should be understood that the communication device of claim 1, the method of claim 14, the system of claim 15, and the corresponding computer program product may have similar and / or identical preferred embodiments, particularly as described in the dependent claims.

[0050] It should be understood that the preferred embodiments of the present invention can also be the dependent claims or any combination of the above embodiments and the independent claims.

[0051] The above and other aspects of the present invention will be described and become apparent with reference to the embodiments described below.

Brief Description of the Drawings

[0052]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

DETAILED DESCRIPTION OF THE INVENTION

[0053] Tags can be used to realize various use cases such as asset tracking or identification. A tag may be attached to an asset, and the ID provided by the tag and received by the reader can identify, for example, the ID of the asset, the type of the asset, the location of the asset, and, when the tag is configured to sense values, for example, including a small sensor, at least one of the sensed values.

[0054] The following embodiments of the present invention are described based on a cellular network positioning (also interchangeably referred to as "location determination" or "positioning") service in which 4G network elements may be incorporated into a proposed 5G solution, for example. Further, at least some of the following embodiments are described based on 5G NR (5G New Radio) radio access technology. However, the present invention can also be used in combination with other radio technologies that can support tags (e.g., IEEE802.11 / Wi-Fi or IEEE802.15.4 / Ultra Wideband Communication (UWB)).

[0055] Throughout this disclosure, the term "wireless network" refers to 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" (4G term) and "gNB" (5G term) refer to access devices such as cellular base stations or WiFi access points or UWB PAN coordinators. The eNB / gNB is part of the RAN, and the RAN can provide an interface to any function within the CN. The RAN is part of a wireless communication network. The RAN implements a radio access technology (RAT). Conceptually, the RAN provides a wireless network infrastructure that exists between communication devices such as mobile phones, computers, remote control machines, etc., and can provide a connection to its CN. The CN is the core part of the communication network and provides various services to customers interconnected via the RAN. More specifically, it transmits communication streams via the communication network and possibly other networks.

[0056] Out-of-coverage and limited-coverage communications In 3GPP (Registered Trademark) specifications TS23.303, 23.304, 24.334, and 24.554 for 4G networks and 5G networks, a so-called ProSe (proximity service) function is defined to enable connections of cellular communication devices (e.g., UEs) outside the coverage of access devices (e.g., eNBs, gNBs). This specific function is called ProSe UE-to-Network (U2N) relay, or relay UE. The relay UE is a communication device that helps an Out-of-Coverage (OoC) UE communicate with an access device (e.g., eNB, gNB) by relaying application and network data traffic bidirectionally between another OoC UE and the access device (e.g., eNB, gNB). The local communication between the relay UE and the OoC UE is called D2D communication, or sidelink communication or PC5 communication. The abbreviation "PC5" represents the interface for sidelink communication defined by 3GPP (Registered Trademark) for 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 the access device (e.g., eNB, gNB) to the communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UEs).

[0057] When the relay relationship is established, the OoC-UE is connected via the relay UE and plays the role of a "remote UE". This situation means that, in contrast to the normal case of direct network connection (see, for example, 3GPP (Registered Trademark) specification TS22.261 v16.10.0), the remote UE has an indirect network connection to the CN.

[0058] Furthermore, in 3GPP (registered trademark) specifications TR23.733 v15.1.0 and TR36.746 v15.1.1, research on architecture enhancements may be provided, such as enabling Internet of Things (IoT) devices (in the role of remote UEs) to operate at very low power by connecting to a wider network using, for example, relay UEs. Since the relay UEs are physically very close, they can be reached using very low power transmission. This work also includes improvements in ProSe security, speed, and stability. These extensions of ProSe are called Enhanced ProSe ("eProSe").

[0059] ProSe can also be used for direct communication between two UEs. For further radio-level details regarding ProSe, V2X, and sidelink communication, see, for example, 3GPP (registered trademark) specifications TR37.985, TS38.300, and TR38.836. However, using this for low-power tags may cause problems because high resources are required to function as an L2 or L3 U2N relay and an L2 or L3 U2N remote UE.

[0060] In addition to the scenario where the tag is outside the coverage (OoC) of the radio network infrastructure, the tag may be within limited coverage (LiC), i.e., the tag can receive transmissions from the gNB but cannot reply due to limited transmission (Tx) power of its own, or conversely, (e.g., because the tag uses a lower-cost and simpler RF receiver than the gNB) the tag cannot receive transmissions from the gNB but can transmit to the gNB (although it may not be possible to determine whether the gNB can receive). Nodes within the coverage of the radio network infrastructure can usually function as (main) anchor nodes.

[0061] Out-of-Coverage (OoC) / Low-Coverage (LiC) can occur for various reasons, such as RF signal blockage by an object or building, limited transmission power of tags, limited transmission energy of tags (e.g., the hardware can generate sufficient transmission peak power but lacks the energy to complete transmission at the required output. This can occur, for example, in energy harvesting tags or battery-driven tags with lifespan requirements), and / or the network infrastructure's entry into sparsely populated areas, and / or the temporary absence of mobile anchors that are statistically assumed to be present. Since nodes such as gNBs in the network infrastructure are mainly used as anchor nodes, this means that for these OoC / LiC tags, their positions cannot be estimated with the desired accuracy. Also, due to the potential difficulty in communication between these OoC / LiC tags and the wireless network infrastructure, the tags may not be able to receive configuration information regarding the execution and setting of corresponding positioning procedures (e.g., transmission time schedule, reception time schedule, transmission parameters, frequency / resource information, payload / reporting format, etc.) from the gNB.

[0062] Figure 1 schematically shows an example of an OoC situation in a location information system with one cell. In the figure, in-coverage tags 101, 102, 103 and out-of-coverage tags 111, 112, 113, all represented by small circles, are located on a 2D plane within the X / Y coordinate system. As shown, tags 101, 102, 103 represented by small white circles can transmit RF signals, and the transmitted RF signals can be received by anchor nodes 121, 122, 123, 124 represented by large circles. Tags 111, 112, 113 represented by small filled circles are OoC and cannot communicate with anchor nodes 121, 122, 123, 124 represented by large circles, but can communicate with nearby tags 101, 102, 103 represented by small filled circles as shown by the bidirectional arrows.

[0063] Therefore, not only transmission from tags to infrastructure but also transmission and measurement from tag to tag may be required. However, in the case of low-power tags, since energy consumption is very low, energy harvesting is necessary, and / or (the battery's) life is required to be very long, transmission and / or measurement by the tag cannot be continuously performed, and 100% wireless reception (Rx) and transmission (Tx) by the tag cannot be achieved.

[0064] RF backscatter communication Low-power tags may have limited energy storage and / or no battery storage at all and may need to use the concept of RF backscatter communication, also called ambient backscatter (in some cases, combined with an energy harvester device). In backscatter communication, information may be modulated onto an input signal (e.g., an RF irradiation signal) from (e.g., a base station or another UE), whereby the modulated signal is transmitted / reflected and can be received by a nearby base station or another UE. Such a backscatter communication method is usually useful for very low-power devices that operate without using an internal energy source during the period of backscatter communication usage, but it is not necessarily the case. Multiple cases (= device classes) are conceivable. 1. The device has an internal energy source that can be used for normal 3GPP (registered trademark) communication but can be switched to backscatter communication for a certain period if necessary to limit the energy consumption from the internal energy source to a very low level or to avoid using any energy from the internal energy source by using some form of energy harvesting such as RF energy harvesting or vibration energy harvesting. 2. The device has no internal energy source, and energy harvesting using RF waves, vibration energy, etc. is the only available energy source. 3. The device has no internal energy source, but in addition to energy harvesting from RF waves or vibration energy, etc., it has intermittent external energy sources such as solar energy, wind energy, thermal energy, and / or salinity gradients. When the external energy source cannot supply sufficient energy, it can rely on energy harvesting from RF waves or vibration energy, etc.

[0065] The cell station and / or UE can directly provide a strong RF signal to the low-power tag. This signal can send data to the low-power tag and supply energy to the RF harvester of the low-power tag. In 3GPP (registered trademark), for a normal UE (e.g., a mobile phone assumed to have an internal power source), support for the scheduling of resources (time, frequency, spatial domain) for control signaling and data traffic in the downlink, uplink, and sidelink, i.e., RRC signaling, downlink control information (DCI), uplink control information (UCI), sidelink control information (SCI), MAC control element (CE), etc., is defined. However, for a low-power tag with a very limited or in some cases non-existent internal energy source, it is not yet clear whether the same resource scheduling method can be reused for the intermittent communication of the low-power tag. Furthermore, in 3GPP (registered trademark), the delivery of the energy transmission schedule and profile from the cell station and / or UE to the low-power tag, and / or the backscatter communication schedule and profile is not yet supported. Since the low-power tag is a lightweight and low-complexity device in the wireless network, it is important to design an effective method to support these aspects in the present invention.

[0066] Position Information System in Cellular Network Embodiments of the present invention are particularly directed to determining the location of a wireless device while using very little electrical energy and using very simple radio on the wireless device within a cellular network. These properties enable the use of small, low-cost battery-powered or battery-less devices within a cellular system. A battery-less device can harvest electrical energy from the environment, such as sunlight, motion, vibration, or RF signals. In the present disclosure, these devices are referred to as "tags" and can be considered as a specific class of user equipment devices (UEs) that may implement a subset of 3GPP specifications. Note that the wireless device can be mobile, stationary, or intermittently mobile and stationary.

[0067] In a location information system, multiple types of devices may participate to provide a location determination function. These types of devices can include tags, more powerful mobile UEs than tags (e.g., smartphones or V2X connected vehicles), or infrastructure devices (e.g., gNBs, mobile gNBs, V2X roadside units). In the present disclosure, the term "node" may be used for such participating devices, and a node can be a UE or a tag can also be a node.

[0068] Some nodes may function as "anchor nodes" or simply "anchors". These nodes are, for example, participating devices that do not move (e.g., fixed infrastructure nodes), or for which cellular positioning techniques (e.g., TDOA) that enable the cellular network to determine the location of the UE are used, or participating devices that can determine their location with high accuracy using a Global Navigation Satellite System (GNSS) (e.g., Global Positioning System (GPS)), and thus are devices participating in a location information system that already has a certain level of accuracy in grasping the 2D or 3D location of the device.

[0069] In some location information solutions, when determining the position of a node, the node can only use measurements to anchor nodes. In other location information solutions, a node can also interact with other non-anchor nodes when determining its own position. The latter is also called "cooperative positioning" or "peer-to-peer positioning".

[0070] For the purposes of the present disclosure, the following three main categories of wireless positioning / positioning solutions may be considered. 1. "Range-based" category: The node measures the mutual range and / or distance to peer nodes. A 2D or 3D position can be calculated from multiple range measurements and some known anchor positions. a. These measurements include techniques such as RF and / or acoustic time-of-flight measurements to measure distance. b. RF time-of-flight measurements typically require a high-bandwidth RF signal and a very accurate (and expensive) clock on the participating nodes. 2. "Range-free" category: The node does not measure range and only measures the presence of peer nodes (e.g., using the ID of peer devices detected via sidelink), or infrastructure devices (e.g., identified using cell ID, E-CID), or a known area (e.g., a service / tracking / registration / coverage area identified using a tracking area identifier (TAI)), and optionally also measures the signal strength indication. a. A 2D or 3D position can be estimated from multiple presence measurements (and optionally signal strength measurements) and some known anchor positions. The estimate can consist of a single position result (i.e., "the most likely position") or a probability model (i.e., multiple position areas tagged with the probability that the node is present there). b. Generally, compared to the "range-based" category, the range-free category consumes less energy, has a lower cost for the node, but also has lower accuracy. 3. Other categories such as arrival / departure angle (AoA / AoD), hybrid, SLAM (simultaneous localization and mapping).

[0071] Embodiments of the present disclosure may target the "range-free" category in an attempt to minimize tag energy usage / complication while compensating for the low accuracy by using presence and optionally signal strength measurements as compared to the "range-based" category, although tags supporting range-based or other location / surveying solutions (e.g., GNSS) are not excluded.

[0072] Location information solutions can also be roughly classified into two categories: real-time and non-real-time. In a real-time location information system, location information measurement / estimation results are provided to an application in real time within a specific guaranteed maximum time delay. This can take milliseconds for some applications and seconds or minutes for other types of applications. In the case of a non-real-time location information system, such strict requirements do not exist. Emphasis is placed on collecting highly reliable records of the past locations of devices / tags / entities, and there may be unpredictable delays in some cases (for example, the data required to appropriately estimate the position of a tag may be obtained hours or in some cases days after the tag is placed in that position). To achieve such highly reliable records, it is important to ensure that measurements are reliably associated with timestamps. The location information service of a non-real-time system must establish the integrity / reliability of the tag's position estimation over time by correlating multiple signal measurements of the tag over a period and forming a reasonable hypothesis about the tag's movement (if any) during that period. This may involve performing procedures such as processing (delayed) tag-sightings related to a tag obtained at a past point in time and retrospectively adjusting the position estimation of that tag at the past point in time (for example, adjusting the trajectory hypothesis of a moving tag over time based on new evidence). Such procedures for updating past information are not typically performed in a real-time system.

[0073] Although the present invention is directed to systems in both categories, in the case of real-time applications that are the most demanding applications (e.g., applications where the location determination latency is from a few milliseconds to a maximum of 1 second for more than 99.9% of the measurements), other dedicated tracking solutions are usually more suitable. Some embodiments provide specific elements most applicable to non-real-time position information systems, e.g., elements that constitute a long tag report reporting period (e.g., several hours or days), elements of out-of-coverage (OoC) operation of tags, or it is provided to include tag sightings in tag reports transmitted within the next time window (which can be minutes or hours after the tag sighting time).

[0074] These wireless location determination solutions utilize RF messages transmitted by nodes, which can be received and logged by nearby nodes. In this disclosure, such RF messages are referred to as "tag reports" or synonymously "tag report messages", and the event of receiving a tag report and the metadata associated with this event is specifically referred to as a "tag sighting" or more generally an "observation report".

[0075] Time synchronization To minimize energy consumption, it may be necessary to transmit intermittently, which can be transmitted every few seconds in one use case and every N minutes, hours, or days in other use cases. If the tag only interacts directly with the infrastructure and / or more powerful anchor nodes (e.g., V2X UEs installed in vehicles), there is no need to time-synchronize the operation of multiple tags. However, in situations with low anchor node coverage (including the aforementioned OoC / LiC tag situations), it is necessary to use measurements between tags to obtain good quality position estimates.

[0076] Therefore, when the sleep time during which the wireless transceiver is off is long or very long, and the tags need to perform peer-to-peer (i.e., between tags) data transmission and reception (see the two-way arrows connecting the small circles in Figure 1) for location identification, it is necessary to synchronize the operations of all the tags involved in time so that all the tags listen for tag transmissions (Rx) during a short time window and all the tags get the opportunity to transmit their respective data (Tx). All this is to enable the infrastructure or network to determine the location of the tags based on the observed measurements of tag data transmissions. It would be ideal if the infrastructure node and / or all the anchor nodes could ensure that the latest configuration information including the time schedule is distributed to all the tags, for example, through broadcast. However, this may not work for OoC / LiC tags.

[0077] Furthermore, when a large number of tags become active within the same narrow time window, there is a risk of mutual interference. Therefore, the time window needs to be made as short as possible to save the energy of the tags, while on the other hand, it needs to be made long enough so that all the tags can transmit without excessive interference. This is based on the premise that all the tags in the area, or a group of tags in the area that is a subset of the entire set of tags, are using the same RF frequency band or channel for transmission while there is a risk of interference. In cellular systems, scheduling is usually used to minimize interference. However, in the case of OoC / LiC tags where it is difficult to easily achieve time synchronization with the gNB of the cellular network, this scheduling becomes difficult. In fact, maintaining an accurate clock consumes energy, so the tags can save energy during their long sleep time by maintaining a less accurate clock. Therefore, even if such OoC / LiC tags transmit according to a pre-set schedule, there is a possibility that the timing and frequency resources overlap with those of the peer tags and interference occurs, or the assigned time window is completely missed if the clock is too inaccurate and / or the time window is short.

[0078] Contact Tracing System and Privacy Protection In a contact tracing system based on wireless signals (e.g., Bluetooth), it is known that the approach to a person of a specific class (e.g., an infected person) with a wireless device can be detected retrospectively without disclosing the identification information regarding the person or the person's wireless device. This can be achieved by transmitting a unique random code to the receiving device, having the receiving device record the received code in a log, and later performing a comparison in a network database. This is also done without disclosing the location information of the persons and / or devices involved.

[0079] It should be noted that privacy protection as carried out in a contact tracing system is also important for a location information system. Unless information disclosure is explicitly intended, no tag should be able to know the ID or location of another tag, including those nearby. In most use cases, the authority to collect data regarding the estimated location lies with entities existing within the network infrastructure rather than the tags. Therefore, other tags (e.g., nearby tags) usually need to be prevented from knowing the location information or identification information of a given tag. However, in many use cases, it is useful and / or acceptable for a tag to know its own location, in which case the tag may disclose information only to authorized parties when necessary.

[0080] Generally, it is desirable that the identification information and / or location information related to a tag, or fragments thereof, are not disclosed to other tags and / or anchor nodes. For example, it is preferable that the display of the transmission power used by a transmitting tag included in a transmitted message is not readable by the receiving entity or node. Also, in order to make it very difficult to perform a location tracing attack on a tag, it is preferable to conceal reusable identifiers (even if they are temporary).

[0081] Known solutions for privacy and confidentiality are to encrypt the information reported by all tags. The receiving entity (e.g., an anchor and / or a tag) stores this information in an encrypted form, and the information data is reported to an authorized location information service within the network. This authorized location information service is the only authorized actor that can decrypt the information based on the key material associated with the ID of each reporting entity. Another known solution based on a contact tracing system is to send a random code, which can later be linked to a specific entity or node that was near another entity at a specific time using a database in a secure location. However, in these known solutions, due to the above privacy reasons, the ID of the reporting tag cannot be included. When millions of different tags that may exist report data, the problem arises of how the location information service can determine which decryption key to use. Also, it is important to provide a privacy and security solution that is compatible with the limited resources of small tags.

[0082] Reliability of Location Information and Replay Attacks Existing methods such as iBeacon (registered trademark) have a problem that if there is no means to verify the reliability of a tag report, the existence of a specific iBeacon (registered trademark) can be faked by recording and replaying the tag report.

[0083] However, even if the location information and / or identification information within a tag report is protected (prevented from being tampered with) by encryption, there is a risk that a malicious entity with access to information recorded prior to the transmission of the tag at one or more locations could conduct recording and replay-type attacks. This entity may claim to have received a tag report from a tag that has never actually sent the tag report to the entity, but the tag report was sent at another time and / or location where there may not have even been a malicious entity. The malicious entity could operate as an anchor node within the location information system. Thus, if one "proper" tag report and one "malicious" tag report are reported to the infrastructure, the location information service within the infrastructure may have difficulty determining who has the correct report, or if both are correct, or if both are incorrect.

[0084] Optimal Control of Transmission (Tx) Power In the case of tags, reducing the average transmission power during transmission and adopting a wireless design with a low peak transmission power are beneficial for suppressing energy consumption and extending the (battery) life of the tags. However, when the transmission power is low, the wireless transmission range becomes small, which has the drawback of reducing the potential number of tag measurements that can be obtained by nearby tags, by anchor nodes, and / or by infrastructure devices. If none of the nearby receivers listen to the tag's transmission, this transmission is useless and wasted. In another scenario where the tag can transmit at maximum (100%) transmission power, while the number of tag observations by other devices (i.e., the number of successful receptions of the tag's data transmission) may be maximized, it may have been possible to achieve the same effect at, for example, 50% transmission power, and energy may be wasted in the tag.

[0085] As a solution, it is conceivable to automatically adjust the transmission power for each tag to an optimal situation. However, such adjustment of the transmission power for each tag may potentially result in a large amount of overhead data traffic when it is under the control or execution of the location information service in real time on the core network (CN).

[0086] Efficient and scalable operation For tags, energy-efficient operation is important. This means that requests to read tags need to be executed efficiently. Efficiency may refer to, for example, energy efficiency, i.e., low energy cost, or time efficiency, i.e., fast. Scalable may refer to the number of tags that can be read simultaneously.

[0087] The 5G system presents an efficient and scalable operation in terms of how devices access the network or the number of devices that can access the network simultaneously. However, even such an efficient procedure may be too demanding for tags.

[0088] Location information system based on RF signal strength and presence measurement FIG. 2 schematically shows an example of a situation in a position information system having one cell according to an exemplary embodiment of the present invention. In the figure, the in-coverage tags 201, 202, 203 (performing transmission between tags as indicated by the dotted two-way arrows), represented by small white circles, are located on a 2D plane within the X / Y coordinate system. Position determination may be performed by the in-coverage tags 201, 202, 203 transmitting RF signals to the anchor nodes 221, 222, 223, 224, which are part of the network infrastructure of the cellular network and are represented by large circles (see the arrows), and the anchor nodes 221, 222, 223, 224 and the tags 201, 202, 203 performing corresponding RF signal measurements. Typically, the RF signal strength of the signals received by the anchor nodes 221, 222, 223, 224 and the tags 201, 202, 203 may be used to estimate the position of the tags. On average, the weaker the signal strength, the farther the tag is located. In such a system, it is generally known that the accuracy of position estimation improves as the number of anchor nodes increases. Also, it is known that the accuracy improves when multiple RF signal strength measurements are made over time and input into a time-based estimation model for the position of a single tag. This time-based estimation model may be based, inter alia, on Kalman filtering, multiple hypothesis Kalman filtering, particle filters, neural networks, hybrids, etc. Although not shown, it is also known that a similar position information system can be outlined by reversing the transmission direction and the reception direction or by performing measurements in both the transmission direction and the reception direction (two-way arrows).

[0089] As defined above, measuring and logging RF signals as tag reports transmitted by a particular tag may correspond to a tag sighting. An infrastructure device (e.g., an anchor node such as a gNB), another type of anchor node, or a tag may be the source of the tag sighting. In existing systems, the recipient of a tag report can usually infer the ID of the transmitting tag from the tag report data, which is a problem in many use cases where devices of multiple owners cooperate.

[0090] Note that the "multi-measurement" strategy, i.e., the strategy of continuously and repeatedly performing tag-based transmission and / or measurement with short sleep times, has a known drawback in that the energy consumption increases linearly according to the number of transmissions and / or measurements. Therefore, this strategy may not be feasible for a very low-power tag location information system, but rather may be applicable to devices (tags) (e.g., mobile robots or phones) that are periodically charged during sessions with a specific limited time (therefore, not constantly over periods such as weeks, months, years, etc.).

[0091] iBeacon (registered trademark), Bluetooth beacon, other beacon systems There are various types of beacon-based location information systems, such as Apple's iBeacon (registered trademark) (iBeacon (registered trademark)) based on Bluetooth Low Energy (BLE). These location information systems are classified into the category of the above location information systems based on RF signal strength and presence measurement. In the case of iBeacon (registered trademark), the tag report can include the unique ID of the tag, and BLE-compatible smart devices within the area receive these tag reports and can report the unique ID of the tag to the location information service together with the estimated location (identified by the receiving device by other methods (e.g., a known GPS / Wi-Fi hybrid location information system)).

[0092] Also, it is known that (BLE) beacons can be configured to transmit position coordinates of a dedicated coordinate system (e.g., a coordinate system for a museum app) or a general-purpose coordinate system (e.g., GPS coordinates). Therefore, a device can estimate its own position by checking one or more tag reports from beacons that include specific coordinate information and the estimated distance to each beacon.

[0093] Definition of terms For convenience, some terms widely used throughout this disclosure are summarized in the following non-exhaustive list of definitions. · Node: A device that participates in a location information system and / or a communication system and / or energy harvesting from an external source to identify the position of a tag, and has RF transmission and / or reception functions. Thus, for example, a core network location information service or a web server on the Internet is not considered a node according to the definition of a node in the present disclosure. · Tag: A device (e.g., a UE) with optional sensor functions, which is a device that should have one of its characteristics. The tag can be mobile, fixed, or intermittently mobile and fixed. The characteristics can be location, sensor value, device type, device status, etc. · Infrastructure Node: Typically a fixed node (e.g., a gNB) that is part of a radio network infrastructure. · Anchor Node: A communication device (e.g., a UE) or an infrastructure node (e.g., a gNB) that has a fixed or known position (e.g., accurately identified by GPS) useful for identifying the position of a tag. · Tag Report: An RF message transmitted from a tag for the purpose of identifying the ID and / or position of the tag. Optionally, the message can include sensor data and / or status information regarding the tag. · Tag Sighting: The reception of a tag report (or tag report message) transmitted by a tag, and the reception of metadata associated with this reception event (e.g., (local) reception time, received signal strength of the tag report message, received signal quality, or the ID of the metadata recipient associated with this reception event, etc.). In the present disclosure, the term "observation report" is used to indicate this specific term "tag sighting" in a more general sense. · SL-UE / Sidelink UE: A sidelink transmission / reception capable UE that can receive a tag report and send the tag sighting to a reporting destination entity (e.g., a gNB of the RAN or a location information service of the CN). The SL-UE may also function as an anchor. The SL-UE can also function as a synchronization source for nearby tags by transmitting sidelink synchronization signals. · gNB: A radio access device (e.g., a base station) of a cellular network. Typically, it is an example of an infrastructure node and / or an anchor node. · Location information service (e.g., Location Management Function (LMF)): A network function of the CN (which may be external to the CN in certain embodiments but is usually a network function of the CN) that can receive information (e.g., tag sightings) and estimate the location of the tag based on all the information and the internal location information model. The location information service provides the location of the tag as a service to an approved application or an approved device. · OoC: Outside the coverage of the radio network (e.g., outside the range of a suitable gNB), and / or outside the range of an anchor node (e.g., a gNB or a UE) associated with a suitable radio network. This definition may include, for example, the following OoC situations of a device. 1. Outside the coverage of a gNB but within the range of one or more anchor nodes. 2. Outside the coverage of a gNB and outside the range of an anchor node. 3. Outside the coverage of a gNB and outside the range of any other node. · LiC: Limited Coverage (LiC) of the radio network, i.e., when a device can receive transmissions from an access device (e.g., a gNB) but cannot reply due to limited transmit (Tx) power. Or conversely, when a device cannot receive transmissions from an access device but can transmit to the access device.

[0094] System Architecture Figure 3 schematically shows a basic cellular location and communication system architecture 300 according to an example of the present invention. Here, for simplicity of representation, a single tag 301 is shown instead of multiple tags. The anchor node 321 of the RAN 320 is the 5G-NR base station gNB 321 represented by a large circle. A single tag 301 within the gNB coverage is represented by a small white circle and periodically transmits a tag report message 330. This message can be received by multiple nearby nodes (as indicated by multiple arrows from the tag). The 5G-NR base station gNB 321 receives the tag report message 330 as a nearby node and reports the tag sighting to the location information service 341 of the CN 340. For example, the CN 340 can be a 5G core network. The CN 340 can include multiple network functions such as a Location Management Function (LMF) or a GMLC (Gateway Mobile Location Centre) configured to manage positioning / location information services provided to a UE (e.g., a tag) or other entities. Note that the location information service 341 in Figure 3 can be another service that only collects reports and then transmits the data to the LMF (or other location information service) in another format, or it can be this LMF (or other location information service). There may be multiple authorized clients 351, 352 (including potential clients within the cloud 351 and potential clients on the UE 352) that are permitted to use the location information calculated by the location information service 441 for specific tags (e.g., only the tags owned by their users). Note that the tag itself (i.e., the same tag whose location is calculated or another tag with legitimate interest in its location information) can be one of the potential clients on the UE 352. The location of the tag is determined based on its proximity to those gNBs at known locations if the tag is within the coverage of one or more gNBs. Note that in this exemplary embodiment, a single gNB 321 instead of multiple gNBs is shown for simplicity.gNB321 transmits the synchronization signal 331 (synchronization signal) and the configuration data 332 to the tag 301. The tag 301 synchronizes with the synchronization signal 331, selects a time window based on the configuration data, and transmits its own tag report message 330 during that time window and receives the tag report message 330 from other tags 301.

[0095] In one embodiment, the tag report message 330 may be transmitted to the gNB321 using one or both of the following methods according to the configuration and conditions. 1. 5G NR sidelink (SL) detection or groupcast / broadcast message. 2. 5G NR uplink (UL) communication. For example, when a tag detects a plurality of gNBs nearby, the tag may switch to a mode where it only performs reporting to these plurality of gNBs via UL communication. In another example, when a tag detects one or more gNBs nearby, the tag may transmit a detection message and a tag report message to that gNB via UL communication to provide additional reliability, confirmation, and / or security, for example, as proof of presence. As another example, when a tag does not detect a gNB (or other access device) nearby, the tag may use only SL detection or groupcast / broadcast messages.

[0096] Note that the first method (1.) is expected to be the lightest and most energy-saving for the tag compared to the second method (2.).

[0097] Also, the exemplary embodiment of the basic system architecture 300 in FIG. 3 shows how this embodiment is integrated into the overall (5G) communication system. Existing communication and signaling formats of 3GPP (registered trademark) New Radio (NR) sidelink detection messages or sidelink groupcast / broadcast messages are reused and extended. For example, to extend the 5G NR standard and implement the embodiments of the present invention, the new parts required may include the following non-limiting list of extensions. - Standardized tag report data format within SL detection or SL groupcast / broadcast messages. This enables all nodes (e.g., tags, UEs, gNBs) to understand and use the same format, and the tag report may include a standardized secure data section. - Standardized format for configuration data (determined by the gNB / RAN and encoded within the tag report message). - Inside the tag: Standard time window calculation algorithm. - Inside the tag: Standard tag sighting selection method (used to selectively include tag sightings in the transmitted tag report). - Between the tag and the location information service / CN: Interface to obtain the tag's temporary ID (i.e., tag temporary ID), or the set thereof if multiple tag temporary IDs exist.

[0098] As schematically shown in the system architecture 400 of FIG. 4, the system architecture 300 of FIG. 3 can be extended by a sidelink-capable UE (SL-UE) 460 that is within the coverage area of the gNB 421 and cooperates to perform tag localization, and an additional tag 411 that is represented by a small solid circle and is outside the coverage area (OoC) of the gNB 421. The SL-UE 460 also functions as an additional tag report collection node in order to receive tag report messages 430-b, 435-b of nearby tags. After receiving the tag report messages 430-b, 435-b, the SL-UE 460 reports the corresponding tag sightings created based on the tag report messages 430-b, 435-b to a reporting entity via the Uu uplink (UL) connection 470 (e.g., directly to the location service 441 (via the gNB 421 that transparently transmits the reported data to the location service 441), or directly to the gNB 421 that it is serving (in this case, the gNB may process the data or may report it to the location service 441 in another format later)). These tag sightings are typically only useful when the location information of the SL-UE 460 is known. This location information may be an approximate location estimated by one or more gNBs based on the SL-UE signal 470, or may be a location determination procedure intentionally performed for the SL-UE 460 using one of the known methods of 3GPP (registered trademark) (e.g., a method using the LPP protocol). Thus, the tag sightings transmitted by the SL-UE 460 may include the SL-UE's own location estimate, or the tag sightings may be extended later using the location information of the SL-UE (e.g., at the gNB 421 or the location service 441). Similarly, the tag sightings may include information regarding the direction of the corresponding received tag report signal (transmitted by the tag), for example, when signal direction estimation based on a multi-element antenna is available on the SL-UE 460.

[0099] As shown in FIG. 4, the SL-UE 460 may provide the sidelink synchronization signal (SL synchronization signal) 433 to the OoC tag 411. This may help to enable the OoC tag 411 (small filled circle) to be transmitted at an appropriate time and frequency without interfering with other data traffic. As shown, the same tag report message 430 transmitted by the tag 401 may be received by different collection nodes. This is represented by the tag report reception event arrows 430-a, 430-b, 430-c. For the tag report message reception 430-c, in this embodiment, it is the adjacent tag (i.e., the OoC tag) 411; for the tag report message reception 430-b, it is the SL-UE 460; and for the tag report message reception 430-a, it is the gNB 421 of the RAN infrastructure 420. In certain cases (e.g., depending on RF signal propagation conditions such as interference), the transmitted tag report message 430 may not be received by all nodes as described above. For example, when the tag 401 transmits three different tag report messages, each message may be received only by one of the nearby nodes, e.g., the gNB 421, the SL-UE 460, and the adjacent tag 411, respectively.

[0100] Although not shown here for the sake of brevity, it should be noted that the SL-UE 460 may also be connected to multiple gNBs, and there may also be multiple SL-UEs capable of providing synchronization signals within the coverage area.

[0101] Energy harvesting In one embodiment that can be used independently, the SL-UE 460 that receives the tag report message 430 which may have a high priority level may increase the transmission power, and / or direct the signal beam, and / or increase the signal bandwidth / density, and / or operate at a higher frequency for one or more transmission signals, and / or transmit another type of high-energy signal (e.g., a signal based on Qi or other wireless power standards) in the direction of the device that is the source of the tag report message 430 or other message and / or in the transmission signal used for communication with the device that is the source of the tag report message 430 or other message. For this purpose, the SL-UE 460 can derive an angle based on the specified arrival angle or the position information in the tag report or other message, and use the derived angle to configure the radio transceiver to generate a signal beam using the beamforming function of the antenna array of the SL-UE 460. Based on the available position information, the SL-UE 460 can also derive the distance between the SL-UE 460 and the device that is the source of the message, and use this to set the signal / beam (e.g., signal strength or beam width). Thereby, the device that is the source of the tag report message 430 or other message can harvest additional energy when the SL-UE 460 transmits energy to the device that is the source of the tag report message 430 or other message. For this purpose, the tag report message or sidelink detection / groupcast / broadcast or other message (e.g., RRC message) that the SL-UE 460 or other node receives from another node or that the node transmits to another node may include a flag or attribute indicating that the node harvests energy (e.g., harvests RF energy to enable communication).Messages received by a node / transmitted from a node (e.g., tag report messages, or sidelink detection / groupcast / broadcast, or other messages) may also include a flag or attribute indicating the type of energy harvesting supported by the node that is the source of the message (e.g., RF-based energy harvesting, which may also include information regarding frequency range, minimum / maximum bandwidth, signal strength, signal type, and / or energy density, solar panel, information regarding Qi). Such a flag or attribute may be added, removed, or modified by, for example, the node that transfers such a tag report, depending on whether the forwarding node itself harvests energy, or a node that creates a tag sighting or other message based on such a tag report or other received message. Alternatively, each node that transfers such a tag report, or creates a tag sighting or other message based on such a tag report or other received message, may add an attribute / flag indicating whether it supports energy harvesting, and / or generate an aggregated message that includes information received from other nodes. Each node may add, within a field / attribute of a message (e.g., an aggregated tag report / tag sighting message) that it transmits to another node, the angle between itself and the node that is the source of the message (e.g., by measuring the angle of arrival), and / or the angle between itself and the node that is the destination of the message (e.g., by measuring the angle of departure).Each node may also add a display of the remaining energy budget (e.g., battery level), the maximum energy budget (e.g., the amount of energy that a capacitor can hold), the energy budget for sending or receiving subsequent messages (e.g., joules or similar units of measurement), a request for the amount of supplied energy (e.g., RF-based), and an estimated time when there is expected to be sufficient energy to receive or send subsequent messages (e.g., calculated according to the current situation or based on (e.g., pre-set information (e.g., information regarding the minimum or maximum amount of available energy and / or the amount of energy at a specific energy density of an RF signal at a specific frequency), or historical data) for a period (a period that may be pre-set) during which it is necessary or expected to be supplied by other nodes or a base station according to the energy level).

[0102] The SL-UE460 and / or other intermediate nodes (e.g., tags, small cell devices) (e.g., an upstream node close to the gNB by one hop, or the gNB itself) that transfer tag reports or other messages may include such functional information (further including information related to frequency range, bandwidth, functions for obtaining angle of arrival, types of energy harvesting, etc.) as part of a ProSe detection / groupcast / broadcast message (e.g., a ProSe identifier, relay service code, or similar identifier that can be preconfigured in another node (e.g., by a ProSe policy) to indicate a function (or a set of functional information) of supplying energy to an energy harvesting device), or as part of an SIB or other periodic transmission message, and provide information related to the function of supplying energy to another node (e.g., a tag). This other node receives this information and can use the information to select a transfer node or determine whether to include the above information related to energy harvesting (e.g., its own energy harvesting function or remaining energy budget). Further, or alternatively, the above other node may use a ProSe identifier or relay service code or similar identifier in a message to the SL-UE460 and / or other intermediate nodes to indicate that it supports energy harvesting and / or requires energy supply for energy harvesting.

[0103] The SL-UE460 and / or other intermediate nodes that forward tag reports or other messages from a first node to a second node (e.g., an upstream node that is one hop closer to the gNB, or the gNB itself) may store, for example, during a communication session between the first node (or a node further downstream or upstream) and the network, or during a pre-set time after receiving a tag report or other message from the first node (or a node further downstream / upstream), such as during the time when a downlink message can be received from the network when the message is forwarded from a downstream node to the network, or during the startup period of the first node or the node itself, the energy harvesting function information received from the first node (e.g., received from a downstream node that is one hop away from the gNB) and / or the angle information (e.g., the angle between itself and the first node). Next, the SL-UE460 and / or other intermediate nodes may use this information to increase the transmission power, and / or direct the signal beam, and / or increase the signal bandwidth / density, and / or operate at a higher frequency for one or more transmission signals, and / or transmit another type of high-energy signal (e.g., based on Qi or other wireless power standards) in the direction of the first node to supply energy to the first node to receive a downlink message or an uplink message from the node or the network, or to enable the first node to transmit subsequent messages.

[0104] In one example, when the gNB, SL-UE460, or other intermediate node generates or receives a downlink message to be transmitted to a downstream node, the gNB, SL-UE460, or intermediate node first supplies a specific amount of energy to the downstream node (e.g., by directing a high-energy signal / beam) based on the information received from the downstream node and / or based on the angle / distance / position information from the downstream node before transmitting the message to the downstream node. In a specific example, the first part of the signal / carrier wave may be purely for energy delivery, and the latter half of the signal / carrier wave can be used for both energy delivery and data delivery.

[0105] In addition to the SL-UE460 or other intermediate node supplying energy to a downstream node, the SL-UE460 or other intermediate node that has received a tag report message 430 (which may have a high priority level) may request the network (e.g., gNB421) to increase the transmission power, and / or direct the signal beam, and / or increase the signal bandwidth / density, and / or operate at a higher frequency for one or more transmission signals, and / or transmit another type of high-energy signal (e.g., a Qi-based signal) in the direction of the device that is the source of the tag report message 430 or other message, and / or in the transmission signal used for communication with the device that is the source of the tag report message 430 or other message, and / or in the transmission signal directed to the SL-UE460. For this purpose, the SL-UE460 may add a flag or attribute to the tag report / tag sighting message sent to the network (e.g., gNB421) to indicate that the tag and / or the SL-UE460 is collecting energy. Optionally, additionally, angle and / or position information and / or other energy collection-related information (e.g., function, remaining energy budget, etc.) related to the SL-UE460 and the source device of the tag report message 430 or other message may also be indicated. Alternatively, a separate message (e.g., an RRC message) indicating such a request and the above information (a subset thereof) may be transmitted.Based on such requests and the provided information, or other information available to the network about the transmitting device of the SL-UE460, the tag report message 430, or other messages (e.g., functional information of the SL-UE460 or the transmitting device of the message that may have been received in previous messages (such as RRC UE function messages) and may include information about the types of energy harvesting supported, and / or IDs received from the SL-UE460 or the transmitting device of the message and / or location data available about the SL-UE460 or the transmitting device of the message, and / or energy harvesting support (which may also include information about the types of energy harvesting supported) that the AMF, gNB, or other network functions can obtain based on the above, and which is indicated (e.g., stored in the UDM / UDR) in the fields of the subscription data), the network (e.g., gNB421) can adjust its transmission mode. For this purpose, the gNB421 can derive an angle based on the required angle of arrival and / or other available location or angle information, and use the derived angle to configure its radio transceiver to generate a signal beam in the direction of the SL-UE460 or the transmitting device of the message using the beamforming function of the antenna array of the gNB421. Based on the available location information, the gNB421 can also derive the distance between the gNB and the SL-UE460 or the device that is the source of the message, and use this to set the signal / beam (e.g., signal strength or beam width).Furthermore, the network (e.g., gNB 42) may recognize (e.g., based on an aggregated message from the forwarding node) that the UE 460 and / or other nodes that transferred the tag report message 430 to the network may be devices that use energy harvesting as an energy source, increase the transmission power, and / or direct the beam, and / or increase the signal bandwidth / density, and / or operate at a higher frequency for one or more transmission signals, and / or transmit another type of high-energy signal (e.g., a Qi-based signal) in the direction of these devices and / or in the transmission signals used for communication with these devices.

[0106] In another embodiment that may be used independently, a communication device that uses energy harvesting (i.e., an energy harvesting device), e.g., the device that transmits / has transmitted the tag report message 430, may increase the transmission power, and / or direct the signal beam, and / or increase the signal bandwidth / density, and / or operate at a higher frequency for one or more transmission signals, and / or in the direction of the energy harvesting device, and / or (e.g., when scheduled to transmit a signal / message with high importance or specific latency requirements) in the transmission signals used for communication with the energy harvesting device, and may be required to transmit another type of high-energy signal (e.g., a signal based on Qi or other wireless power standards) to / for a different device (e.g., UE460) in the tag report message 430 or a PC5 message (e.g., a detection message), and / or via a direct connection to the network (e.g., an RRC or MAC message transmitted to the gNB via Uu), and / or via an indirect connection to the network (e.g., an RRC message transmitted to the gNB via an L2 U2N relay).For this purpose, the tag report message 430 or other messages sent to the network or other devices may include, or indicate, the (estimated) location or the known latest location of the low-power tag device, a priority indication, a message type (e.g., an emergency SMS), a delay / latency indication, the device's energy harvesting function (e.g., the frequency range for RF-based energy harvesting), the remaining energy budget (e.g., the battery level), the energy budget for sending or receiving subsequent messages (e.g., in joules or similar units of measurement), a request for the amount of energy supplied (e.g., RF-based), and an estimated time when there is expected to be sufficient energy to receive or send subsequent messages (e.g., under the current circumstances, or calculated according to a certain period (a pre-settable period) based on (e.g., pre-set information (e.g., information regarding the minimum or maximum amount of energy available, and / or the amount of energy at a specific energy density of an RF signal at a specific frequency) or historical data), or according to the energy level that needs to be supplied or is expected to be supplied by other nodes or base stations during a certain period). Based on such a request, the network (e.g., gNB 421) and / or another device (e.g., UE 460) can adjust its transmission method (e.g., by directing a high-energy signal beam towards the direction of the energy harvesting device). The energy harvesting device may adjust its antenna / radio settings after sending such a request.

[0107] In one example, the energy harvesting device may include the display of one or more high-priority messages to be transmitted within a sidelink detection / groupcast / broadcast or other sidelink message (e.g., by including an emergency flag in a tag report or by including an identifier indicating the use of an emergency service (e.g., a relay service code)), and / or by transmitting an RRC message, MAC control element, or dedicated buffer status report or scheduling request indicating a high-priority message to be transmitted to another device (e.g., UE460 or gNB421), the display of the high-priority message may be included. A message including such a high-priority display may be the message itself (e.g., to avoid wasting unnecessary energy and because the energy harvesting device may have additional high-priority messages to transmit). Upon receiving such a display, the other device may include such a high-priority display in the message to be forwarded or transmitted to another node after receiving the message from the energy harvesting device. Also, the other device may increase the transmission power and / or direct the signal beam and / or increase the signal bandwidth / density and / or operate at a higher frequency for one or more transmission signals and / or transmit another type of high-energy signal (e.g., a signal based on Qi or other wireless power standards) in the direction of the energy harvesting device. Also, the other device may increase the transmission power and / or direct the signal beam and / or increase the signal bandwidth / density and / or operate at a higher frequency for one or more transmission signals and / or be involved in the transfer of messages from / to the energy harvesting device and transmit another type of high-energy signal (e.g., a signal based on Qi or other wireless power standards) in the direction of another node that has indicated (e.g., in an aggregated message) that it is performing energy harvesting.Further, or alternatively, the other device may be required to transmit power to, and / or direct a signal beam, and / or increase a signal bandwidth / density, and / or operate at a higher frequency for one or more transmitted signals, and / or transmit another type of high-energy signal (e.g., a signal based on Qi or other wireless power standards) in the direction of the energy harvesting device. To enable this, the other device may transmit a message that includes position information (e.g., distance and / or angle information and / or estimated geographical location) of the energy harvesting device that enables other nodes to determine an angle for beamforming in the direction of the energy harvesting device. The other device may also include a time schedule or other configuration information (e.g., frequency band or type of signal to be used) that can be used by the nodes to determine when and how to transmit a high-energy signal in the direction of the energy harvesting device. The other device may also transmit such a time schedule and / or configuration information to the energy harvesting device that needs to transmit high-priority messages. Thereby, the energy harvesting device can adjust its antenna / wireless configuration based on the received time schedule and / or configuration information.

[0108] In an additional embodiment that can be implemented independently, to facilitate beam steering or to configure the schedule or settings for the supply of RF-based energy to the energy harvesting device, the tag and / or the energy harvesting device can simply provide feedback regarding the received beam (e.g., for energy transmission or downlink data transmission). This is because the processing capabilities of the tag or energy harvesting device are limited. This can be achieved by including in the tag report or other message a flag / attribute indicating that additional energy for harvesting has been received (e.g., at a scheduled time or at a time that can be reported within the tag report or other message), and / or information regarding the amount of energy received during a pre-set time, a reference time (e.g., as indicated in the RRC measurement configuration message), or a time after a scheduled time (e.g., using the above time schedule), or the time since the last message was sent or received, or during a pre-set period, or during a period indicated by a series of timestamps added to the report (e.g., energy budget / battery level difference), and / or the amount of energy received at a specific point in time or measured over a certain period (e.g., joules / second or similar measurement units), and / or information regarding the beam index (e.g., SSB index) of one or more of the strongest beams that may be measured within a pre-set period.Optionally, if a specific time corresponds / matches a pre-set time (e.g., the time from a reference time (e.g., the time since the last message such as an SIB, or a downlink message, or the time offset, or the time since the last message was sent)), the timestamp (e.g., the timestamp of energy reception, measurement execution, report generation, message transmission and reception) may be omitted from the tag and / or the tag report or other message sent by the energy harvesting device (in some cases, a small tolerance / pre-set variation may be allowed). Alternatively, an index of a series of pre-set times may be sent (e.g., each index may indicate a different time offset, or a different reference time, or different reference signals that the energy harvesting device may receive, such as a downlink signal containing a specific flag or attribute value).

[0109] In other words, a wireless communication device (e.g., a UE or an access device) may be configured to obtain an indication that a second wireless communication device (e.g., a tag) can perform energy harvesting (e.g., by receiving from the second wireless communication device a message containing a flag or attribute indicating the same, or by obtaining such information associated with the ID of the second wireless communication device from subscription information or functional information stored in the wireless network), obtain the angle (and / or distance) between the wireless communication device and the second wireless communication device, and configure a wireless transmitter operated by the wireless communication device to transmit a high-energy signal / beam in the direction of the second wireless communication device.

[0110] Such a wireless communication device may be further configured to obtain an angle by performing an angle-of-arrival measurement with respect to a message received from a second wireless communication device and / or by determining an angle (and / or distance) between the wireless communication device and the second wireless communication device based on the estimated positions of the wireless communication device and / or the second wireless communication device.

[0111] Such a wireless communication device may further receive from the second wireless communication device a message regarding a high-priority message scheduled to be transmitted by the second wireless communication device (the message received from the second wireless communication device itself may be a high-priority message), and may be configured to determine whether to transmit a high-energy signal / beam in the direction of the second wireless communication device based on the priority of the message.

[0112] Such a wireless communication device may further be configured to transmit to a third wireless communication device a message including one or more of the following information, and the third wireless communication device may use this information to determine whether to supply energy to the wireless communication device and / or the second wireless communication device. - An indication of the energy harvesting function of the second wireless communication device, - An indication of the energy harvesting function of the wireless communication device, - Angle, distance, or (relative) position information related to the wireless communication device and / or the second wireless communication device, - An indication of high-priority messages transmitted by the wireless communication device and / or the second wireless communication device, - A request to transmit a high-energy beam towards the wireless communication device and / or the second wireless communication device (the request may include timing information and / or configuration information).

[0113] Such a wireless communication device may be further configured to transmit a message including information regarding its function of supplying energy to a second wireless communication device to the second wireless communication device.

[0114] Furthermore, the second wireless communication device (e.g., a tag) may have an energy harvesting storage function (e.g., a capacitor) and may be configured to include an indication in a field / attribute of the tag report message indicating that the second wireless communication device is capable of energy harvesting. Further, it may be configured to set a wireless receiver operated by the second wireless communication device to receive a high-energy signal / beam for energy harvesting.

[0115] The second wireless communication device may be configured to include information regarding the amount of energy received after a preset time or reference time, or during a preset time interval or reference time interval, in a field / attribute of the tag report message.

[0116] Backscatter communication In additional embodiments that can be used independently or in combination with other embodiments, a low-power tag device can transmit a secure report message by reflecting colliding RF signals from an access device (e.g., a base station or a communication device providing sidelink services) as part of RAN1030 using the concept of RF backscatter communication. For this purpose, the system / method / device used to generate a signal to an energy harvesting device may be applied to generate a backscatter communication signal to a backscatter communication device, where the "energy harvesting device" is replaced by a "backscatter communication device" and the "energy harvesting function" is replaced by a "backscatter communication function". Additionally or alternatively, the colliding signal may include a type identifier field indicating the type of identifier (either a device identifier or a device group identifier) within the identifier field. The identifier field may include an identifier of an individual low-power tag device and / or an identifier of a group of low-power tag devices. This may be, for example, one of the pre-set temporary IDs (temp-ids) of the tag device as described in other embodiments, or a part thereof (e.g., a predetermined / pre-set number of bits / bytes of the identifier to be matched, or a temporary ID value to be matched). The tag device can determine whether to transmit / modulate a response as part of the colliding signal by checking whether the identifier in the colliding signal matches any of these pre-set temporary IDs (or a part thereof).

[0117] Deployment example of a location information system In an exemplary embodiment of the present invention, FIG. 5 schematically shows an example deployment of a location information system based on the system architecture 400 of FIG. 4. This deployment in a 2D plane within the X / Y coordinate system includes anchor nodes that are 5G NR base stations (e.g., gNBs 521, 522, 523, 524 represented by large circles), SL-UEs 561, 562 (represented by rectangles) that are UEs passing through the coverage area with stronger signal than the tags, OoC tags 511, 512, 513 (represented by small filled circles), and in-coverage tags 501, 502, 503 (represented by small white circles). The SL-UEs 561, 562 and the tags 501, 502, 503, 511, 512, 513 can perform NR side-link communication and can also transmit or receive side-link detection or side-link group cast / broadcast messages according to 3GPP (Registered Trademark) TS38.300 (Release 16). Different from the tags 501, 502, 503, 511, 512, 513, the SL-UEs 561, 562 can also implement the transmission of side-link synchronization signals according to 3GPP (Registered Trademark) TS38.331 (Release 16), 3GPP (Registered Trademark) TS38.300 (Release 16), 3GPP (Registered Trademark) TS38.211 (Release 16), and 3GPP (Registered Trademark) TS38.213 (Release 16). Therefore, the SL-UEs 561, 562 can function as SyncRef UEs. As indicated by the arrows, the in-coverage tags 501, 502, 503 can transmit tag report messages to multiple gNBs 521, 522, 523, 524. Although not shown in the figure, note that since the tags 501, 502, 503, 511, 512, 513 are within the gNB coverage, the tag sightings may be directly transmitted to the gNBs 521, 522, 523, 524 within a secure unicast. As indicated by the arrows, the tag report message may be transmitted from a tag (e.g., 501) and received by a peer tag (e.g., 511). Based on the reception of the tag report, the peer tag may create a tag sighting by combining the information of the received tag report with specific metadata that describes the tag report reception event.The same process applies when a tag report received by a tag (e.g., 501) is sent by a peer tag (e.g., 511). Thus, as indicated by the bidirectional arrows connecting the small circles, the process functions bidirectionally. Note that a single tag report sent by a tag (e.g., 501) within the coverage of one or more anchor nodes (e.g., gNB521, 522) is received by peer tags (e.g., 511, 512) and anchor nodes within range. The dashed arrows indicate SL synchronization signals 531, 532, 533 sent from SL-UEs 561, 562 acting as SyncRef UEs to tags 511, 512, 513, where tags 511, 512, 513 are OoC tags that can use the synchronization signal as a time reference instead of using the time reference from the gNB. The dashed "Uu" 570-a, 570-b indicates that SL-UEs 561, 562 are optionally also connected to gNBs 521, 522 and are within their coverage (the connection between gNB521 and SL-UE561 and the connection between gNB522 and SL-UE562). Note that when outside the gNB coverage, the SL-UE may function as a SyncRef UE under specific conditions defined in Section 5.8 of TS38.331. Also, when within the gNB coverage, the SL-UE may function as a SyncRef UE under specific conditions. In an optional embodiment, an SL-UE within the gNB coverage but far from the gNB (determined, e.g., by measurement of signal quality or signal level and subsequent comparison with a threshold) can send a sidelink synchronization signal to assist nearby OoC tags in synchronizing their internal time reference.

[0118] Direct communication Figure 8 schematically shows a signaling and processing diagram of a communication process between an access device and tags according to an embodiment of the present invention. In this embodiment, which can be combined with other embodiments or used independently, an access device 831 (e.g., a base station or a communication device providing sidelink services) that is part of a radio access network (RAN) 830 transmits a request 851 for obtaining the ID or location of a tag to communication devices 801, 811 serving as tags. These requests 851 can be, for example, a synchronization signal (e.g., MIB) and system information (e.g., SIB1) that indicates the function of reading the tag. These requests may be independent signaling messages for the tags. This function may be indicated using a specific closed access group (CAG) ID or other identifier having a similar purpose (e.g., a group ID). When the communication devices 801, 811 receive their respective requests 851, they may transmit respective replies 852 providing their respective ID and / or location information to the access device 831 (as described in other embodiments of the present invention). The access device 831 may forward this respective reply 852 to another entity within the core network (CN) 840, such as a server 841 providing a location estimation service.

[0119] When the access device 831 is a base station, the reply 852 may be an initial physical random access channel (PRACH) extended to directly include the (protected) ID of the communication devices 801, 811, thereby avoiding further round trips and / or energy consumption.

[0120] When the access device 831 is a communication device providing sidelink services, the request 851 can be, for example, a sidelink synchronization signal, an announcement detection message, or a sidelink broadcast / groupcast message, and the reply 852 can be a detection message or a sidelink broadcast / groupcast message.

[0121] In one embodiment, the access device 831 may filter or limit the amount of response 852 to be transferred based on the CAG being used or a related identifier, or based on the ID or location of the communication device.

[0122] FIG. 9 schematically shows a signaling and processing diagram between an access device and a tag, including an authentication procedure between a network and a tag, according to an embodiment of the present invention. In this embodiment, which can be combined with other embodiments, an access device 931 (e.g., a base station) that is part of the RAN 930 transmits a request 951 to obtain the ID or location of the communication device 901. These requests 951 can be a synchronization signal (e.g., MIB) and system information (e.g., SIB1) that provides an indication of the function of reading the tag. This function may be indicated using a specific CAG ID or other identifier having a similar purpose (e.g., a group ID). When the communication device 901 receives the request 951, it may transmit a random access request 952 as a reply. The access device 931 may assign a temporary RAN ID 953 to the communication device 901. The communication device 901 may transmit an identification request / network access request / location identification request 954 to the CN 940 via the access device 931, where the ID may be protected as described in other exemplary embodiments of the present invention or as a 5G SUCI. This message may also include other features / sensed data stored / measured by 901. As described in other embodiments of the present invention, the ID or such features / sensed data may be transmitted as part of a tag report, and the network can thereby identify the tag and / or monitor / track the tag. The tag report may also be included in this message. This message may be used by the network to identify the location of a specific tag upon successful identification. The CN 940 (and / or the server 941 that provides the location identification service) may obtain an approximate estimate of the location of the communication device 901 based on the participating access device 931.

[0123] Optionally, for example, subsequent authentication procedures (955, 956) between the communication device 901 and the CN 940 may be performed based on the confidence level that the CN has for message 954. This authentication procedure may be based on primary authentication.

[0124] Optionally, message 953 may be skipped and messages 952 and 954 may be combined.

[0125] This procedure is advantageous because the access device can request / obtain the identification information / features / sensed data of the tag device 901 with minimal interaction.

[0126] Figure 10 schematically shows a signaling and processing diagram between an access device and a tag in which tags within coverage rebroadcast requests from the access device. In this embodiment, which can be combined with other embodiments, an access device 1031 (e.g., a base station or communication device providing sidelink services) that is part of RAN 1030 transmits a request 1051 to obtain the ID, location, or data of communication devices (1001, 1011). These requests 1051 can be a synchronization signal (e.g., MIB) and system information (e.g., SIB1) that provides an indication of the function to read tags. This function may be indicated using a specific CAG ID. Communication device 1001 is located within range, while communication device 1011 is not located within range. There may be a policy set in the communication device to request rebroadcast of request 1051, or this command may be included in the request itself. The request may include a parameter indicating the number of times the request should be rebroadcast, and the communication device 1001 that performs the rebroadcast may decrement this parameter each time it performs a rebroadcast. The rebroadcast request 1052 may reach communication device 1011, and communication device 1011 may prepare a report and transmit a reply 1055 as described in other embodiments of the present invention. Communication device 1001 may wait for a maximum time for the reception of a second report 1055 transmitted by a second communication device (e.g., 1011) that may be located outside the coverage. If the second report 1055 arrives before the rebroadcast request 1052 arrives, communication device 1001 can calculate its own report and transmit an integrated report 1057 towards the access device 1031 of RAN 1030, including the received second report 1056. The access device 1031 can forward this reply within message 1058 towards another entity within the core network 1040, e.g., a server 1041 providing a location service.

[0127] In embodiments that can be combined with other embodiments or implemented independently, the reply of the communication device (e.g., 852 in FIG. 8) can be determined by an ID (e.g., the ID of the communication device or the protected (hashed, encrypted) ID of the communication device), or transmitted using timing and frequency resources that depend on the beam used to access the communication device. This is shown in FIG. 11, where the horizontal axis represents timing resources, the vertical axis represents frequency resources, and the blocks within the grid represent the same time / frequency resources. This is the number of carriers used to transmit an orthogonal frequency division multiplexing (OFDM) symbol. Devices (1101, 1111, 1112, 1121) are assigned to different blocks. A given device with a resource block may have to listen (for other transmissions) before sending a reply, and / or wait for a random period within the block before sending, and / or wait for a random period (in discrete increments) before sending. This has the advantage that a single access device can process more tags.

[0128] In embodiments that can be combined with other embodiments or used independently, the request message (e.g., message 851 in FIG. 8) may include setting a set of time windows or frequency resources that the communication device (e.g., device 801 in FIG. 8) may use.

[0129] In embodiments that can be combined independently with other embodiments, the setting of a set of time windows or frequency resources that may be used by the communication device (e.g., device 801 in FIG. 8) can be performed during an online or offline initial setup phase.

[0130] In one variant, the device (e.g., 801) may determine a possible resource set based on the initial message 851. For example, the MIB / SIB1 may implicitly / explicitly determine / indicate the resources or resource set to be used in the random access procedure. The device 801 may then further select the specific resources / resource set to be used based on its own ID. For example, the specific resources may be a function of its own ID, a function of other device parameters (e.g., tag type, physical location), or other implicit / explicit indications.

[0131] Iterative transmission and data duplication In additional embodiments that can be used independently or in combination with other embodiments, the communication device may receive from the access device settings regarding support for iterative transmission and / or data duplication (e.g., SIB broadcast, RRC settings). In the case of iterative transmission, the communication device receives from the access device the setting of the number of iterative transmissions N (N >= 1), and then, in the actual transmission of the secure report message, the communication device may repeat the data N times in the physical / MAC layer that may be multiplexed in time, frequency, and / or spatial domain. The receiving side of the iterative transmission in the access device can combine (partially or completely) the received copies of the physical packets and apply joint decoding of the packets to extract the secure report message. In the case of data duplication, the communication device receives settings on how duplicate data can be transmitted in application layers such as the PDCP layer and / or the RLC layer, and then, at the actual transmission of the secure report message, the communication device uses one or more RLC entities to transmit the same PDCP packet, and the receiving side (e.g., the receiving-side communication device or the access device) can detect / discard the duplicate PDCP packets.

[0132] Energy harvesting / transmission scheduling In additional embodiments that can be used independently or in combination with other embodiments, nodes in a wireless network (e.g., low-power tag devices, UEs, or separate RF energy supply units) receive resource allocation messages (e.g., RRC signaling, DCI / SCI messages, MAC control elements) from an access device 1031 (e.g., a base station) as part of RAN1030, or from a UE or other communication device (e.g., SL-UE 460) that can provide sidelink services. The resource allocation message indicates to nearby energy harvesting devices (e.g., low-power tag devices) to transmit energy at specific time intervals. The energy to be transmitted is an RF signal within a pre-set frequency range (e.g., 80 kHz to 300 kHz in the case of Qi, or a 4G / 5G cellular frequency band, or an IMT unlicensed band (e.g., a band that enables transmission at high transmit power)), and can be an RF signal having a (pre)-set transmit power selected / requested / preferred by the low-power tag device. The resource allocation message may further indicate frequency range information, beam direction information, and transmit power information. Such information may be pre-set using previous messages (e.g., RRC messages or SIBs) sent to each node. The access device 1031 (e.g., a base station) that is part of RAN1030, or a UE or other communication device that may provide sidelink services, may schedule similar resources for the energy harvesting devices (e.g., low-power tag devices) to receive their respective energies.An access device 1031 that is part of RAN 1030, or a UE or other communication device that can provide sidelink services, may set different resource schedules according to the distance, angle, relative position of the access device and the energy harvesting device, and / or the number of communication devices near the energy harvesting device that may be useful for transmitting high-energy signals / beams towards the energy harvesting device and / or that provide sidelink services for communicating with the energy harvesting device, and / or the number of other energy harvesting devices located near the access device. The resource setting may include multiple different resource schedules, and / or the access device 1031, or a UE or other communication device that may provide sidelink services, may select different energy transmission parameters (e.g., transmission power) that can be selected by the access device 1031, or a UE or other communication device that may provide sidelink services. This selection may be made according to the measured / estimated distance and angle between the communication device providing sidelink services and the nearby energy harvesting device (e.g., low-power tag device). The access device 1031, or a UE or other communication device that may provide sidelink services, may receive a message (e.g., an aggregated tag report / signaling message) including information about the energy harvesting function of the energy harvesting device and intermediate nodes involved in transferring messages from the energy harvesting device to the access device 1031, or a UE or other communication device that may provide sidelink services, and / or angle / distance / position information related to these devices and the energy harvesting device.

[0133] In one example, the resource allocation message is a dedicated DCI / SCI format / type for scheduling energy harvesting related signals. In a specific example, a first communication device capable of sidelink communication requests a second communication device to transmit a high energy signal to the first communication device via the sidelink by transmitting a dedicated SCI. The request may include information regarding timing, frequency, and priority. The second communication device may respond with another SCI to confirm and notify the first communication device that it will transmit a high energy signal. The response may include timing information and frequency information related to the high energy signal that the second communication device will transmit to the first communication device.

[0134] Similarly to the above, a tag that receives energy and / or an energy harvesting device or an intermediate node (e.g., the first communication device described in the previous paragraph) based on this type of resource allocation schedule may provide feedback on the received energy. This can be achieved, for example, by including in a tag report or other message a flag / attribute indicating that additional energy for harvesting has been received (e.g., at a scheduled time or at a time that can be reported within the tag report or other message), and / or by including in the tag report or other message information regarding the amount of energy received during a preset time (e.g., the time when the resource was allocated), or after a scheduled time (e.g., using the above resource allocation schedule), or the time since the last message was transmitted or received, or during a preset period, or during a period indicated by a series of timestamps added to the report (e.g., energy budget / battery level difference), and / or information regarding the amount of energy being received at a specific point in time (e.g., joules per second or similar unit of measurement), or the amount of energy measured during a certain period.

[0135] In other words, a wireless communication device (e.g., a UE or an access device) may obtain an indication that a second wireless communication device is capable of energy harvesting (e.g., by receiving from the second wireless communication device a message including a flag or attribute indicating the same, or by obtaining such information associated with the ID of the second wireless communication device from subscription information or functional information stored in a wireless network), and may be configured to schedule resources of a second or third communication device. The second or third wireless communication device may use these resources to configure a wireless receiver operated by the wireless communication device to receive a high-energy signal / beam and harvest energy using the same, and / or to configure a wireless transmitter operated by the wireless communication device to transmit a high-energy signal / beam towards an energy harvesting device.

[0136] Wake-up signal for an energy harvesting low-power tag device In additional embodiments, which may be used independently or in combination with other embodiments, a low-power tag device receives a wake-up signal from an access device 1031 (e.g., a base station or a communication device providing sidelink services) that is part of RAN 1030, and is configured to activate an energy harvesting device (e.g., the low-power tag device) and / or a group of energy harvesting devices (e.g., low-power tag devices) to collect energy from an external source (also referred to as a peripheral source), and / or is configured to transmit a first secure report message. The wake-up signal may include device identifiers and / or device group identifiers of the devices and / or device groups that are to be triggered to start the energy harvesting process and transmit and receive secure report messages.

[0137] In additional embodiments that can be used independently or in combination with other embodiments, the low-power tag device can be configured to periodically activate to detect the presence of a wake-up signal that may be transmitted at a specific frequency at a specific time (e.g., frame / sub-frame / slot / symbol). The specific time opportunity may be randomized differently for each energy harvesting device (e.g., low-power tag device) and / or for each group of energy harvesting devices (e.g., low-power tag device groups) based on the device identifier of the energy harvesting device (e.g., low-power tag device) and / or the device group identifier of the group of energy harvesting devices (e.g., low-power tag device). The specific frequency resource for transmitting the wake-up signal may be fixed or may be based on a pre-set frequency hopping pattern to utilize the diversity of the radio channel. In FIG. 12, energy harvesting devices (e.g., low-power tag devices) 1201 and 1202 can periodically activate at each set time and frequency within the resource grid to detect the presence of the wake-up signal transmitted by access device 1031. If the wake-up signal is detected, the device may further decode the content of the wake-up signal packet for further processing. If the wake-up signal is not detected, the device stops the radio transceiver and returns to the sleep mode until the next wake-up opportunity pre-set by the access device.

[0138] The wake-up signal may use the multi-carrier OOK (On-Off Keying) method, which is also defined in IEEE802.11ba-2021. Further, the wake-up signal may use the multi-carrier ASK (Amplitude Shift Keying) method, the multi-carrier FSK (Frequency Shift Keying) method, or the CP-OFDMA (Cyclic Prefix - Orthogonal Frequency Division Multiplexing Access) method. The wake-up signal may be embedded in the 4G / 5G OFDMA downlink resource grid. Guard bands exist at both ends of the wake-up signal frequency band, and guard times exist at one or both ends of the wake-up signal in the time domain, compensating for the low-precision time / frequency synchronization of the wake-up signal to the network. The low-power tag device may track the time / frequency of the network using the synchronization signal (SSB, PSS / SSS / PBCH) from the base station and / or the sidelink synchronization signal from the SL SyncRef UE. The access device may additionally transmit a low-power synchronization signal (LP-SS) for the low-power tag device to track the time / frequency of the network, thereby synchronizing the low-power tag device with a low-cost clock or without a clock to the access device. The wake-up signal may use a sequence-based design such as the Zadoff-Chu sequence to represent a limited number of information bits, or may use encoded bits over multiple time / frequency resources to transmit a larger number of information bits. In one embodiment, the wake-up signal functions as a collision signal for backscatter communication, and the low-power tag device can start immediately upon receiving the collision wake-up signal and reflect / modulate the collision signal to transmit a tag report message.

[0139] FIG. 13 shows an example of a wake-up signal packet. In addition to potential header and CRC fields within the packet, the packet may further include a type field indicating the purpose of the wake-up signal. Examples of purposes include waking up an energy harvesting device (e.g., a low-power tag device) to collect energy from an external source (also called an ambient source), and / or waking up an energy harvesting device (e.g., a low-power tag device) to receive downlink data from access device 1031, and / or waking up an energy harvesting device (e.g., a low-power tag device) to transmit uplink data to access device 1031. The packet may further include a type identifier field indicating the type of identifier (device identifier or device group identifier) within the identifier field. The identifier field may include an identifier of an individual energy harvesting device (e.g., a low-power tag device) and / or an identifier of a group of energy harvesting devices (e.g., a low-power tag device). This may be, for example, one of the pre-set temporary IDs (temp-ids) of the tag device as described in other embodiments, or a part thereof (e.g., a predetermined / pre-set number of bits / bytes of the identifier to be matched, or a temporary ID value to be matched). The tag device can determine whether to wake up by checking whether the identifier in the wake-up signal matches any of these pre-set temporary IDs (or a part thereof). To prevent an incorrect wake-up signal from interfering with the operation of the tag, the wake-up signal packet may include a secure section data field or another field that functions as a message integrity check. When receiving a wake-up signal, the tag can calculate the secure section data field using its own temporary tag ID or another assigned group ID, and check whether it is the intended recipient of the message.To assist in determining which ID a tag should use, a "group" flag or a few bits of index value may be sent in the wake-up message.

[0140] Figure 14 shows the procedures of energy harvesting devices (e.g., low-power tag devices) 1201 and 1202 that are operated by a wake-up signal transmitted by access device 1031. The details are as follows. S1: Access device 1031 pre-sets wake-up setting information for energy harvesting devices (e.g., low-power tag devices) 1201 and 1202, and the wake-up setting information may include information on the time and frequency at which the tag device wakes up periodically to detect the presence of the wake-up signal. S2: When it is the scheduled time for the tag device to wake up to detect the wake-up signal, the tag device proceeds to step S3; otherwise, the tag device maintains the sleep mode. S3: The tag device wakes up to detect the presence of the wake-up signal. S4: If the tag device detects the presence of the wake-up signal at the pre-set time and frequency, the tag device proceeds to step S5; otherwise, the tag device proceeds to step S8 and enters the sleep mode. S5: The tag device further decodes the content of the wake-up signal packet. S6: If the content of the wake-up signal packet indicates that the packet is for the tag device by means of a device identifier or a device group identifier of the device group to which the tag device belongs, the tag device proceeds to step S7. Otherwise, the tag device proceeds to step S8 and enters the sleep mode. S7: The tag device completes the operation requested by access device 1031 and proceeds to step S8 and enters the sleep mode. S8: The tag device enters the sleep mode.

[0141] In some cases, even the periodic processing of wake-up messages may be too energy demanding for the tag device and / or, in some cases, as in some embodiments of the present invention, the tag device may not be able to keep track of time. In some cases, as in some embodiments of the present invention, the tag device may not be able to activate, for example, to monitor the presence of a synchronization signal / MIB from an access device. In such cases, further embodiments of the present invention are applicable, and an initial message may be sent, for example, to perform the initial procedure of FIG. 14 or to provide the tag device with enough energy to determine whether to perform the initial step of FIG. 8. The tag device uses this initial message to check whether it is required to activate / reply. If this is confirmed positively, the tag may use energy from its own energy source (e.g., harvested energy). For example, a tag device having a photodetector / small solar panel (e.g., a device that harvests energy from light) may receive an initial message (optically encoded message) that instructs it to use such an energy harvesting device to perform the procedure of FIG. 14 and / or FIG. 8. Thus, this initial message is powered by the light source of the incident light and may not consume energy for the tag device. If the initial message contains a given identifier or if the initial message can be successfully verified (e.g., if it contains a MIC), the tag device can proceed to subsequent steps where the device tag may need to consume energy, as shown, for example, in FIG. 8 or FIG. 14.

[0142] In a variant, the reception of this initial message may also function as a timing reference, similar to a synchronization signal indicating when subsequent messages, such as the wake-up signal of FIG. 14 or SIB1 of FIG. 8, will be received. This is advantageous because the tag device does not need to keep track of time to perform the actual wake-up operation.

[0143] In the variant form, this initial message is a physical layer message, and the device tag only needs to monitor specific physical characteristics of the signal. For example, it only needs to monitor whether the signal is modulated at a specific frequency or whether the modulated frequency follows a given pattern. For example, a light source can be modulated (e.g., the amplitude is modulated by switching on / off at frequency fc), and such modulation can be detected by a photodetector.

[0144] In the variant form, upon receiving the initial message, configuration information (e.g., regarding timing and / or frequency resources) for transmitting a tag report is implicitly set in the tag device, and / or the tag device is implicitly triggered to transmit a tag report.

[0145] In embodiments that can be combined with other embodiments or implemented independently, an access device, UE, or intermediate node that can supply an energy harvesting signal to an energy harvesting device (e.g., the low-power tag device described in this application) may use different types of energy harvesting signals. The first type of energy harvesting signal may be used to supply energy to the energy harvesting device (e.g., using a high-energy beam) without requiring the device to be activated. The second type of energy harvesting signal may be used to supply energy to the energy harvesting device (e.g., using a high-energy beam) and to trigger the energy harvesting device to activate immediately after or within a predetermined / pre-set time after collecting sufficient energy. For this purpose, the second type of energy harvesting signal may use a specific frequency, frequency shift, some signal peaks, or signal patterns, or have other detectable signal characteristics that the receiving energy harvesting device can distinguish from the first type of energy harvesting signal. When the energy harvesting device receives an energy harvesting signal of the first type, it may be possible to determine that the device can continue to be in a sleep state (even after collecting sufficient energy), or when it receives an energy harvesting signal of the second type, it may be determined that the device needs to activate if possible (e.g., immediately after collecting sufficient energy or within a predetermined / pre-set time after collecting sufficient energy).

[0146] gNB and Sidelink-Based Clock Synchronization More specifically, the OoC tags synchronize with the sidelink synchronization signals transmitted by the respective nearby SL-UEs, while the in-coverage tags synchronize with the synchronization signals transmitted by the gNB. According to the SL synchronization procedure defined in 3GPP (registered trademark) TS38.331 (Release 16), when the SL-UE is within the coverage of the gNB, the synchronization signal (SL synchronization signal) transmitted by the SL-UE is synchronized with the timing of the gNB. Alternatively, when the SL-UE is out-of-coverage (OoC) of the gNB, if a component GNSS is incorporated, the SL-UE may use a GNSS (e.g., GPS)-based timing reference. Thereby, it is time-synchronized with all nearby gNBs whose timing is based on Coordinated Universal Time (UTC) reference time. With this time synchronization of the tags, the tags within the coverage area (i.e., the tags within the coverage of the gNB or the SL SyncRef (synchronization reference) UE connected to the gNB) can use a common time reference, so that the time window for transmitting and receiving tag reports can be clearly determined.

[0147] In an optional embodiment, the synchronization signal transmitted by the gNB and / or the synchronization signal (SL synchronization signal) transmitted by the SL-UE may also be used to provide configuration data.

[0148] In an optional embodiment, for detecting / decoding the wake-up signal, the low-power synchronization signal for the wake-up radio receiver in the low-power tag device to track the time / frequency of the network may also be used for clock synchronization of the low-power tag device.

[0149] Transmitting a tag report without a clock synchronization / reference signal Even in an exemplary scenario where the OoC tag cannot find either the gNB signal or the SL SyncRef signal used for time window calculation, the OoC tag may send a tag report using an optional method. In this case, the OoC tag may listen to the tag reports sent by nearby tags within the coverage of the gNB or SL-UE (i.e., nearby tags can receive synchronization signals from the gNB or SL-UE). Immediately after receiving this tag report, the OoC tag may then send its own tag report on the same frequency / channel resource and based on the configuration data included in the received tag report. This method works when the specified frequency / channel resource is 100% available for SL in general or specifically for tag transmission, i.e., when it is not time multiplexed with other cellular communication purposes such as uplink (UL) / downlink (DL). Using this method, the transmission of the OoC tag's tag report is very likely to occur within the allocated time window, so this information can still be used for OoC tag localization as described in the present invention. The advantage of this method is that the system becomes more robust against coverage loss and loss of the (SL-UE based) temporary synchronization source.

[0150] As another example, the OoC tag may calculate the transmission time based on multiple tag reports received from nearby tags. That is, when an OoC situation without a synchronization signal is detected, the tag keeps the radio on for a longer time to obtain one or more tag reports, and then may infer and set the time window and frequency to be used (the time window is an approximation). For example, if such an OoC tag receives a tag report at time t1 that includes configuration data (config-data) indicating that the sleep period (the period when the radio transceiver is disabled) for transmitting the tag report is 30 minutes and the duration of the time window is 10 seconds, the OoC tag sleeps for about 29 minutes and 49 seconds and then turns on the radio to receive the next tag report or a series of tag reports for the next period (>11 seconds). The OoC tag may set the timing so as not to miss the next time window based on the received configuration and the estimated drift / inaccuracy of its internal clock. In this exemplary alternative method, since the maximum estimated clock drift of the tag is 1 second over the entire sleep period, the tag can sleep for 29 minutes and 49 seconds before re-enabling its radio receiver. In the case of a perfect internal clock without drift, the OoC tag can sleep for 29 minutes and 50 seconds. By repeating such a cycle one or several times, the OoC tag can be relatively well synchronized with the time windows used by other tags within the coverage area even without an external time synchronization signal. Note that this technique works most effectively when the OoC tag can (and is permitted to) transmit data in a non-slot manner rather than the normal slot communication scheme defined for existing 5G NR UL / DL / SL communication.

[0151] In another example scenario where there is no SL-UE within the system architecture 400 of FIG. 4, the OoC tag cannot confirm the timing reference or synchronization signal from the "missing" SL-UE, and thus cannot derive the time window required to perform transmission with sufficient accuracy. In such a case, the OoC tag may stop transmitting until it can resynchronize to the timing reference.

[0152] In another alternative scenario example where the tag is configured to function as a synchronization source for OoC tags (e.g., directly configured by the gNB via DL, and this does not necessarily have to be a 5G NR SL synchronization signal, and could be, for example, a new, lighter, and more power - efficient one), the tag as a synchronization source may perform one or more of the following steps. - Transmit an additional tag report message at a predefined time (e.g., at the start or end of a time window). - Include additional synchronization / time data in a tag report message that is readable by other tags. Even if including this additional synchronization / time data is triggered, it is not necessarily required. - During the period of the time window, periodically transmit a specific (new) type of synchronization signal on an adjacent RF channel or the same channel.

[0153] Note that the drift of the internal clock may be estimated based on the known inaccuracy of the tag's timing circuit (e.g., a crystal oscillator). Since the expected maximum inaccuracy depends on temperature, measurement of the circuit temperature may be required to accurately estimate the drift. If temperature measurement is not available, the worst - case temperature may be assumed based on the tag's effective temperature range.

[0154] As an example of another method for clock drift detection and correction, it is conceivable that tags within coverage include timestamps in their respective tag reports in a format that can be analyzed by the receiving - side OoC tags (e.g., not encrypted or encrypted with a key known to the entire group). With such timestamps, the receiver can calibrate its own clock and calculate an estimate of the clock drift since the timestamp was last received. This estimate can be used to adjust the reception frame shown as "11 seconds" in the above example. For example, using a more accurate drift estimate, the OoC tag can listen for a time window of 10.4 seconds instead of 11 seconds, saving the tag's energy.

[0155] Next, the OoC tag may mark a special "out-of-sync coverage" for sending its tag report message, for example, by using a bit flag in the public data section of the tag report message, so that other OoC tags do not use its transmission as a reference again. Also, since the OoC tag does not receive a time stamp format based on the system frame number (SFN), it cannot use that format. Therefore, it may be advantageous for the OoC tag to indicate another time stamp format, such as an estimated SFN or simply an internal sequence number (ISN), etc., within its tag report message.

[0156] Time synchronization of tags using a collective / shared tag report time window In one exemplary embodiment, a tag may select a time window for sending and receiving tag report messages based on the "config-data" parameter that is distributed as configuration data to all in-coverage tags by the gNB. In one example, all gNBs may periodically send this configuration information in a System Information Block (SIB) data structure. To enable UEs and tags located at remote locations outside the coverage to use this data, a sidelink UE or relay UE functioning as a SyncRef UE may also periodically send this SIB data. In-coverage tags may repeat the received configuration data as a single "config-data" element within their tag report messages, thereby enabling out-of-coverage tags to also receive the configuration information. Similarly, out-of-coverage tags receiving this configuration information may include the "config-data" element again in their tag report messages, thereby enabling tags further outside the coverage to receive the relevant configuration. This may always be performed in an optional embodiment, but in another optional embodiment, it may be performed only based on the result of a decision algorithm. For example, if there is not enough space to include the configuration in the tag report message, the configuration may not be included, and vice versa. Alternatively, as another exemplary embodiment, a configuration bit (flag) may indicate to include "configuration data" for the tag report of the OoC tag, and the configuration may be included only if there is sufficient space remaining within the tag report message. Note that it should be noted that the size of the tag report message may depend on the number of tag sightings included and other factors.

[0157] In the exemplary embodiment of FIG. 4, the tag can select a random time within the time window for transmission and attempt to broadcast a sidelink detection message at the selected time. Based on the existing 3GPP (registered trademark) NR V2X mode 2 (i.e., mode 2 of resource selection defined for NR SL communication), an appropriate "available" resource is selected at that time, or if there is no available resource at that time, it is selected at the next time. If the tag detects that its transmission is interfering with another transmission or is very close in time to another transmission, it may randomly select a new available time slot to use for repeating the tag report transmission. Also, the tag may select a new channel within the same time slot and repeat the tag report transmission on that new channel. This embodiment attempts to enable dynamic adjustment of the density of tags within a geographical area and / or the number of tag report messages while minimizing the length of the tag reception time window.

[0158] Embedding configuration data into synchronization / reference signals In one embodiment, the synchronization signal used by the tag to determine the transmission timing can be used to embed a few bits of configuration data ("config-data") that the tag can decode. This synchronization signal can be the SL signal transmitted by the SyncRef UE, the synchronization signal transmitted by the gNB, or both. This can be useful if the tag does not want to expend the energy to receive and decode the complete RAN configuration data broadcast as part of the master information block (MIB) / system information block (SIB).

[0159] Message type of tag report - ProSe PC5 direct detection message In an exemplary embodiment of the present invention, the message used for the tag report may be a ProSe PC5 direct detection message type of 3GPP (registered trademark) TS24.554 (Release 17). "Open detection" where all tags in the area can participate in the protocol (e.g., "Open 5G ProSe direct detection announcement") may be used, or "restricted detection" may be used if specific key material is pre-installed in each tag of a group of tags that cooperate while excluding tags of other groups. Note that the term "group" of tags may refer to all tags in an area / country, a group of tags owned by a specific organization, or tags implementing a specific application standard, etc.

[0160] "Open detection" can be used with or without additional encryption protection. In the present disclosure, it is used without additional encryption protection only for simplicity.

[0161] Note that in the current ProSe specification, often an appropriate (detected) candidate UE is selected following the reception of the detection message, and the communication link is started using a ProSe direct communication request (DCR). This DCR is not used in the current detection messages defined for location determination. As tags generally may not even implement DCR and ProSe PC5 direct communication, this is not a problem. In fact, tags use only the detection message to transmit the tag report. For the SL-UE that receives the tag report, the (pre)configuration of that UE needs to be specifically set so that the UE operates as an "anchor" that transmits the tag sighting to the network after collecting the tag report without triggering a meaningless DCR to the tag. This can be easily set based on a specific property of the detection message, e.g., a specific relay service code (RSC) or set of RSCs that is only associated with the location determination of the tag and not with other ProSE direct communication services that the SL-UE can implement.

[0162] According to an exemplary embodiment of the present invention, another example of a property of a ProSe direct detection message that can be used to indicate the purpose of a message as a tag report is bits 1 and 2 of the "detection model value" in the header. Of the possible four 2-bit combinations, two are each used to indicate model A / B, and the other 2-bit combinations can also be used for such purposes. For example, "00" may be used to indicate a tag report message model.

[0163] Structure of Tag Report In one embodiment, a tag report or tag report message may include a plurality of fields used to identify a tag and specify the location of the tag (including retrospectively specifying the location of the tag, which would be useful for a non-real-time location system). The tag report may include at least the following fields. - Configuration data (config-data). - Timestamp. - Transmit power indication. - Secure section data.

[0164] Furthermore, the tag report may include a vector (or set, collection) of tag sightings that includes information about the tag report observed by the tag upon receipt of the tag report. That is, for each tag sighting, the data of the tag report is included, and the metadata associated with that tag report may be included.

[0165] Note that the brackets {} in the following relational expressions represent the composition of data items (or parameters or elements), such as concatenation, TLV (a tag, a length and value) structure, ASN.1 (abstract syntax notation one) structure, CBOR (concise binary object representation) object, etc. The square brackets [ ] in the following expressions indicate optional elements and are included only if the relevant data transmitted within those elements is available.

[0166] In one embodiment, the tag report may be given by the following relational expression. tag-report={config-data,timestamp,tx-power,secure-section-data,[Tag-sightings]} (1) Here, Tag-sightings is an optional field that is an array of length 1, ···, N. Thus, Tag-sightings={Tag-sighting-1, ···, Tag-sighting-N}. The maximum value of N may be determined as a constant applicable to the implementation of a specific embodiment, or may be determined algorithmically by the sender.

[0167] The form of a single basic Tag-sighting-i (i = 1, ···, N) is represented by the following relationship. Tag-sighting-i={tx-power,rx-power,timestamp,secure-section-data} (2)

[0168] As can be seen from the formula, the "config-data" item may be removed from the relational expression (2) of tag-sighting-i. This is because, as defined in the relational expression (1), it has already been sent once in the tag report. As a result, the payload size of the tag report is significantly reduced. Usually, at a specific time and specific location / cell, all tags use the same configuration data "config-data". This usually holds because this data is not changed very frequently. Since "config-data" is set and / or distributed by the RAN of a specific area, the currently used value of "config-data" and the previously used value of "config-data" are also known to the RAN and the core network / location service. For example, if the setting is changed at a certain time T and the RAN and CN / location information service receive tag sightings made before time T, the RAN and CN / location information service can deduce that this was sent using the old configuration data. If the RAN determines the configuration data independently of the location service, or determines the configuration data based on input parameters / data transmitted from the location service to the RAN, the RAN can inform the location service of the determined configuration data when necessary, or as part of the tag sighting data transmitted from the RAN to the location service.

[0169] "Config-data" Structure In one embodiment, the "config-data" structure may be kept very small to reduce the payload size of the tag report and may have an encoded form. For example, it may be 8 bits and may encode the following parameters. - Specific frequency band / resource to be used, predefined (3 bits). - Specific time schedule (5 bits). Both are from a predefined set of options. However, note that the "config-data" structure may use more data bits to describe a finer schedule.

[0170] As an example, Table I below shows option settings that can be predefined for frequency bands. [Table 1]

[0171] For the frequency band value, the following special cases can be considered. If the necessary frequency band is sensed by searching for SL tag reports in all supported bands and selecting the band with the most tag reports found, the value is "6". If the tag cannot send a tag report, the value is "7". The frequency band value "4" defines a frequency hopping sequence N instead of a fixed channel / RB set. Here, N is defined by a time schedule parameter.

[0172] As an example, Table II below shows a subset of option settings that can be predefined for time schedule parameters. [Table 2]

[0173] In the second column above, t0 may be defined as a reference UTC time such as 01-Jan-2021 or 01-Jan-1900 as used in (5G NR 3GPP (registered trademark) TS38.331 (Release 16)).

[0174] Adjustment of tag timing by the tag learning its optimal transmission time and automatically extending the time slot if necessary In one embodiment, an additional tag timing adjustment mechanism can be used to avoid all tags within an area starting to send tag reports simultaneously or sending tag reports within a (limited) subset of the same multiple time slots within a time window. The term "time slot" here is used to represent the period during which a tag report message can be completely transmitted in a slotted wireless communication system. In this exemplary embodiment, the "time slot" is assumed to be equal to the 5G NR slot period. However, note that the "time slot" is not necessarily the same as the 5G NR slot period and can be shorter (e.g., one symbol period, two symbol periods, etc.) or longer (e.g., two 5G NR slots, or longer). The third column in the above table shows optional settings that can be predefined for time scheduling parameters, but the "target duration" of the time window may be defined for any setting data index value related to the time window. Thus, each tag can first monitor the RF messages received during this time window on the permitted channels and then record the relative time within the time window when other messages may be received. Based on this, each tag can randomly select a time slot within the target time window and the corresponding channel that is still "available" (i.e., no transmission has been received on that time slot and that channel). However, if there are no available time slots or the percentage of occupied time slots exceeds a threshold (e.g., >90%), the tag can apply an algorithm to temporally extend the default slot and randomly select one of the available time slots within this temporally extended slot. Since this time slot extension may be different from the existing 3GPP (registered trademark) NR V2X mode 2 of the basic embodiment (i.e., mode 2 of resource allocation defined for NR SL communication), it may be necessary to use a new L2 / L1 (PHY / MAC) mechanism instead in 5G NR SL.This required alternative approach may be useful, for example, when the energy requirements of the existing SL mode 2 approach are too high and a more efficient new scheme is needed. However, the time slot extension itself may be used in combination with the existing SL mode 2 resource allocation.

[0175] Format of the time stamp In one exemplary embodiment, the format of the time stamp may be encoded as any of the following. - A part of the system frame number (SFN) (e.g., the most significant 6 bits (MSB)) is wrapped around and encoded as the time stamp value (e.g., 6 bits or 10 bits). - Representation of UTC time (e.g., the least significant N bits of a specific encoding of UTC time such as the number of seconds since January 1, 2022). - An internal timer value (e.g., 16 bits or 32 bits) that is loosely synchronized to the SFN so as to estimate the drift of the internal clock of the tag using the SFN and correct the drift. - A sequence number that increases by +1 for each tag report transmission. For example, it may have a length of 8 bits, 16 bits, or another length and may return to 0 after reaching the maximum value (e.g., 255). - Lamport time stamp value or vector clock value. - Some combinations of the above: for example, a time stamp value and a sequence number.

[0176] Transmission power format and control within the tag by policy In one exemplary embodiment, as part of the "config-data" bits, a specific transmission power control policy may be optionally or additionally indicated to the tag. Such a policy can control the transmission power used by the tag to send a tag report. The transmission power may be a 4-bit value that refers to a pre-defined table of 16 possible transmission power level settings for the tag.

[0177] Examples of 16-bit "config-data" that include a transmission power control policy may include the following. - Predetermined frequency band to be used (3 bits). - Specific time schedule (8 bits). - Transmission power policy selection (5 bits).

[0178] First, the "config - data" bits can indicate a transmission power policy that defines a specific default transmission power level. The default is used when the tag sighting within the time window is below a specific threshold NT1 (network termination 1) (i.e., tag sighting < NT1, which indicates that the RF channel / band in use is "not busy" in the local area).

[0179] Next, when there are more tag sightings (i.e., tag sighting ≧ NT1, which indicates "busy"), the tag automatically reduces its transmission power by a pre - agreed amount to reduce tag sightings of neighboring tags, and thus automatically transitions to a "less busy" state in the RF channel / band used within its geographical area.

[0180] Third, when the number of tag sightings is below a specific threshold NT2 (network termination 2) (i.e., tag sighting < NT2, which indicates "hardly any others are seen"), the tag may automatically increase its transmission power by a pre - agreed amount to increase tag sightings of neighboring tags. This can be useful in sparse environments.

[0181] Fourth, the policy may define what to do when there are only tag sightings with a very low received signal strength (received level) despite the transmission power of the tag sighting (indicated in the "transmission power display" field) being relatively high. In that case, the tag may infer that it is far from all other tags and may increase its transmission power by an amount determined by the policy.

[0182] Received power format In one embodiment, the "received power" item can be an 8-bit value that references a pre-defined table of 256 received signal strength indication (RSSI) values for tag sighting. In another exemplary embodiment, the value may reference 256 possible reference signal received power (RSRP) values for tag sighting, in which case the RSRP is identified by the receiver by measuring the power of a specific part of the tag report signal that includes a reference signal sequence. Note that the tag report may include several reference signal parts, i.e., "header" or "start symbol".

[0183] Secure section data structure In an exemplary embodiment, the "secure section data" item can be a fixed-length binary sequence such as, for example, 128 bits, 256 bits, or 512 bits. The optimal length may also depend on the security properties of the secure section data, for example, it may be based on the encryption function used or the encryption key (length) used. Note that the tag sighting includes the secure section data itself obtained from the sighted (i.e., received) tag report.

[0184] In a simplified exemplary embodiment, for simplicity, it is assumed that the tag may not sign / authenticate the tag sightings it reports. However, in other exemplary embodiments, the tag may sign / authenticate the tag sightings it reports to enhance location information security / prevent tampering. Signing the tag report in which the tag sighting is embedded allows a location information service that collects and verifies all tag sightings to verify that none of the tag sightings embedded in the tag report have been added, deleted, or changed, thereby improving the reliability of the derived location information estimate and the resistance to this type of data modification attack.

[0185] In this simplified exemplary embodiment, the secure section data may be the output of an encryption function F(.) for specific data items, and the vertical bar | represents data concatenation to a sequence. The secure section data is represented by the following relational expression. secure-section-data={F(tag-temp-id|config-data|timestamp|tx-power|status-bits)} (3) Here, F(.) can be a cryptographic hash function, or another hash-based message authentication code (HMAC) function that uses an encryption key in combination with a hash function, or a block cipher-based message authentication code (CMAC) algorithm that can be used to guarantee the reliability and thus integrity of binary data. The function F(.) may further include a truncation operation (TRUNC) or a Boolean operation (e.g., XOR) in any configuration, as shown in relational expression (5).

[0186] In relational expression (3), the "tag-temp-ID" item and the "status-bit" item are used by the tag when creating the secure section data of the tag report, but are not included as clear text data in the tag report message. That is, the location information service needs to infer the values of these items by, for example, searching a secure database using the hints described below (in the case of "tag-temp-ids"), or trying all bit combinations in a brute-force manner (in the case of "status-bits").

[0187] In this simplified exemplary embodiment, the "tag-temp-id" item serves as a symmetric "secret key" known only to the tag itself and the location information service. This is the reason why it requires a sufficient length (e.g., at least 128 bits) to avoid a brute-force attack on guessing the temporary ID tag-temp-id.

[0188] In this exemplary simplified embodiment, the "status-bit" item may be 4 bits and may include the following. - Battery status indicator bit (1 = OK, 0 = low battery). - Compact delta encoding of the sensor value of the sensor on the tag (00 = no change, 01 = value increased by +1, 10 = value decreased by -1, 11 = sensor value returned to a pre-set threshold). Thereby, the location information service can reconstruct the actual sensor value over time based on multiple tag reports from the same tag. - gNB coverage indicator bit (1 = within coverage, 0 = outside coverage).

[0189] Cryptographic function using HMAC and optional salt In one exemplary embodiment, the tag report and the cryptographic function F(.) can be defined as follows based on HMAC. tag-report={[config-data,][salt,]timestamp,tx-power,F(.)} (4) F(.)=XOR(TRUNC(HMAC(tag-temp-id,[config-data]|[salt]|timestamp|tx-power),40),status-bits|0x00000000) (5) Here, - HMAC(K,A) calculates the HMAC of A using the key K. - TRUNC(A,B) returns B bits of A (e.g., the B least significant bits of A). - XOR(A,B) performs a bitwise XOR operation on the bit strings A and B. - A|B performs the concatenation of the bit strings A and B - salt is an optional random "salt" parameter used as a cryptographic salt selected by the tag. This can also be regarded as a nonce. - config-data is optionally indicated to cover embodiments with and without config-data included. - The status bit is 8-bit status data determined by a tag.

[0190] In this exemplary embodiment, the optional "sort" item / parameter may be used to further add bit changes to the input of the function HMAC(.), and also to optionally add additional randomness. For example, if the timestamp is selected such that it does not change very frequently (e.g., the timestamp is updated only every minute), and other inputs such as status bits, transmission power, config-data, etc. do not change during that period, in such a situation, there is a risk that the same tag report that cannot be distinguished from the previous one may be generated. This can cause, for example, an undesirable situation where an attacker traces both tag reports to reach the same node, or the attacker later "replays", i.e., resends, the tag report, causing confusion with the genuine tag report generated by the node. Therefore, the sort can be particularly useful in avoiding those risks. Recognized threats. And depending on the resources available to the tag, the sort can take various forms. In some embodiments, for example, the sort may include a simple sequence counter that increases with each transmission. In other embodiments, the sort may include any random number specific to each transmission or a random number generated by encryption. In either case, the sort needs to be long enough to prevent the previous value from being reused within a given time interval. When the sort parameter is used in the calculation of HMAC(.), the sort value also needs to be included in the tag report. Also, the relevant sort value (obtained from the associated tag report that was witnessed) needs to be included in each tag witness data. This allows the location information service to finally calculate the cryptographic function using the correct sort value. Note that the above relational expression (4) of this exemplary embodiment indicates that the sort value is optionally included in the tag report, and although it is not included here for simplicity, in the case of other exemplary embodiments, the tag witness data may also be included.

[0191] The gNB / CN that receives the tag sighting data may transmit this to the location information service. The location information service obtains all tag-temp-ids that are known to be within or likely to be within the area of interest, calculates the HMAC as shown, and obtains the 40-bit LSB of the output (i.e., TRUNC(x,40)). Thus, the location information service can determine whether the reported tag-temp-id is appropriate by comparing the calculated value with the least significant 32 bits (LSB) (4 bytes). Next, the server performs an XOR operation on the secure section data, i.e., the F(.) component within the received tag sighting, and the calculated truncated HMAC(.) value, and obtains the most significant 8 bits (MSB) (1 byte) of the result to obtain the status bit. In this exemplary embodiment, the integrity of the status bit is not protected, but the status bit is included in the tag report, providing the advantage of a confidential state. This saves the location information service from having to iterate through all possible status bit values to guess the correct status bit value, saving calculation time in the location information service and allowing for longer status bit sequences (e.g., 224, 128, or 96 bits instead of just 4 or 8 bits).

[0192] Assignment of tag-temp-id values In one exemplary embodiment, the core network (CN) may securely assign one or more temporary IDs (i.e., the "tag-temp-id" field or tag-temp-id) to each tag, for example, through a location information service. This is done using normal 3GPP (registered trademark)-defined communications such as a direct connection to the gNB (via UL / DL) or a relay connection via a UE-to-Network relay UE (via SL). Also, in case the tag (e.g., an OoC tag) cannot reach the CN during operation, a tag-temp-id may be pre-set on the tag. These values are stored in a secure storage element on the tag. Since the location information service also knows the pre-set tag-temp-id values through a secure database search, it may try a number of tag-temp-id values for tags known to be near a particular gNB service area based on previous tag reports or connection log information for the gNB. When the location information service finds a tag-temp-id value that matches the value used by the tag in the calculation of secure section data, the calculation result of the assumed secure section data by the location information service using that tag-temp-id value matches the secure section data received within the tag sighting. This enables the location information service to identify a particular tag from among a large number (e.g., millions) of tags.

[0193] In one exemplary embodiment, the tag-temp-id values may be assigned as cryptographically random values of, for example, a length of 128 bits or more. These tag-temp-id (IDs) serve a role similar to that of a temporary symmetric key for security.

[0194] The tags may periodically (e.g., once a week) establish a full connection session to the RAN and CN, and use this session to obtain updates of one or more tag-temp-id values from the location information service. These can be securely transmitted to the tag and stored within the secure storage space in the tag. This can only be performed when the tag is within the coverage of the gNB or within the coverage of a suitable UE-to-Network relay UE that can provide a connection service to the tag. Note that in order to conserve the energy of the tag, the execution of this is noted to be minimized.

[0195] Tags having multiple pre-stored tag-temp-id (IDs) may cycle through these IDs based on a pre-defined policy (e.g., a timer that limits the usage time of a single ID), or may cycle through the IDs based on the UTC time / SFN transmitted by such a node when the tag is within the coverage of the gNB or relay UE. Using pre-stored IDs can be useful for tags that are out of coverage for a long period or, in some cases, for the entire duration of their lifespan. Specific means of cycling through the tag-temp-id also include calculating the value of the tag-temp-id based on a hash function F(timestamp,tag-id), where "tag-id" is the fixed ID of the tag and "timestamp" is the timestamp at the time when the calculation is performed. In this case, the tag reports the same "timestamp" value within its tag report structure, and the location information service can thereby derive the same tag-temp-id that the tag used.

[0196] In one exemplary embodiment, one or more tag-temp-ids may be pre-set within the tag prior to deployment in the field (e.g., at the factory, by the vendor, etc.), such that the tag can operate even when not within the gNB coverage or relay coverage. In another embodiment, the pre-setting can be performed in the field using a dedicated tool that uses, for example, short-range communication (e.g., BLE, Wi-Fi, or 5G NR SL D2D communication, or NFC).

[0197] As part of the tag report, a temporary ID protected by a hash function without using status bits In one exemplary embodiment, the temporary ID (i.e., the "tag-temp-id" item or simply tag-temp-id) can be provided as part of the tag report in a lightweight manner (e.g., without using standard encryption methods, without including status bits, by using a hash function H(.)), according to the following relational expression. tag-report={timestamp,tx-power,H(tag-temp-id|timestamp|tx-power)} (6)

[0198] The "tag-temp-id" item is included in the hash calculation but may not be transmitted via the wireless communication channel. The location information service needs to spend resources to try all possible combinations, e.g., thousands to millions of known tag-temp-ids within a specific target area (which can be defined as a gNB / cell or an intersection area of two or more gNB cells). Although not included in the above relational expression (6) of this exemplary embodiment, in the case of other exemplary embodiments, the "config-data" item may also be included. To reduce the bandwidth usage and power consumption of the tag, the "config-data" item may be included only in a subset of the transmitted tag report messages.

[0199] Transmission of Encrypted Status Bit Data In an exemplary embodiment, when it is necessary to transmit a larger amount of status bit data, but the status bit data still needs to be in a confidential state with integrity protected, the encrypted status bits may be included in the tag report of the above relational expression (6). Optionally, the transmission power field and the timestamp field may also be encrypted, but this is not shown in the above relational expression (6). Therefore, the tag report and the secure section data can be represented by the following relational expressions respectively. tag-report={config-data,timestamp,tx-power,secure-section-data} (7) secure-section-data={E(tagK,status-bits),F(tag-temp-id|config-data|timestamp|tx-power|E(tagK,status-bits))} (8)

[0200] As shown by the above formula, the secure section data may include encrypted status bits within E(.) in addition to the encrypted F(.) part. Here, E(tagK,status-bits) is an encryption function that encrypts the "status-bit" data using the (secret) key "tagK" of the tag.

[0201] On the other hand, the location information service may have a corresponding key or the same key for decrypting the status bits again according to the following relational expression using the function D(.). status-bits=D(tagK’,encrypted-data) (9) Here, D(tagK’, encrypted-data) is a decryption function for decrypting the “encrypted-data” data using the key tagK’. The keys tagK and tagK’ can be defined by or derived from the location information service in the same way as tag-temp-id. In the case where tagK == tagK’, symmetric key encryption is used. In the case of asymmetric (i.e., public key / secret key based) encryption and decryption, tagK may be the public key used for encryption and tagK’ may be the secret key used for decryption. The advantage of the asymmetric option is that even if an attacker can compromise one tag or multiple tags, it may not be possible to obtain tagK’ required for decrypting (previous and / or future) recorded messages including E(tagK, status-bits). In fact, for the attacker to obtain tagK’, they need to attack the location information service infrastructure itself, which is usually more strongly protected than a low-cost embedded device such as a tag, making the attack less likely to succeed.

[0202] In other exemplary embodiments, the function F(.) can be calculated for the true values of the status bits instead of the encrypted value E(.) as shown by the following relational expression. secure-section-data={E(tagK,status-bits),F(tag-temp-id|config-data|timestamp|tx-power|status-bits)} (10)

[0203] In this case, it is the role of the location information service to perform multiple calculations of F(.) using not only the data immediately available from the tag report but also the decoded status bits as inputs. In other words, for each hash calculation F(.), the location information service first needs to execute the decoding function D(.) using the corresponding stored key, which increases the computational load. However, this has the advantage that it becomes difficult for an attacker to start a brute-force attack by trying a large number of tag-temp-id values. By combining with the above asymmetric option, there may be another advantage that an attacker who obtains the public key tagK stored in the tag still cannot execute the function D(.) to obtain the status bits. This makes it very difficult for an attacker to decrypt the tag report sent and recorded by the tag in a brute-force manner (e.g., by iterating a large number of potential tag-temp-id generated). This is because the attacker does not have the input value "status-bits" required to perform such calculations.

[0204] Transmission of a hint or digest of the tag temporary ID as part of the tag report In an exemplary embodiment, a hint or digest of the tag-temp-id may be communicated within the tag report to assist the location information service in quickly searching for thousands to millions, or more, of tag-temp-ids. The length of the digest may be settable to enable the system to scale. This setting may be part of a profile selected by the "config-data", or part of a separate "config-data" field indicating the length of the digest in bits. For example, a 2-bit digest reduces the hash calculations required by the location information service by an average of 75%, but discloses little about the true ID of the transmitted tag.

[0205] Hints can be calculated in various ways. For example, they can be calculated by obtaining the tag-temp-id every N bits, or by obtaining a single parity bit calculated for the tag-temp-id.

[0206] In other embodiments, the tag may receive in a downlink message (e.g., a wake-up message or a tag configuration message) (e.g., from the network or an access device, UE, or intermediate node) a hint that the tag needs to use within the tag report. In one variation, a complete hint used within the tag report may be created by combining a hint mask included in the downlink message with elements of the tag ID. For example, the supplied hint may be XORed with the last few bits of the tag identifier, or a selected portion of other predefined bits. Thereby, the network can efficiently change the hint used for a group of tags within a single wake-up message. Since hint collisions can be resolved by the network, they do not need to be unique.

[0207] Transmitting information regarding the next tag wake-up time within the tag report In an exemplary embodiment, the tag may transmit in the tag report information that identifies or helps identify the next time slot at which the tag wakes up again to execute a new tag report or to listen for a tag report. By receiving this information, several scenarios can occur as follows. - If a neighboring tag receives information regarding the next wake-up time for transmission, that tag may adjust its wake-up schedule to perform reception at that time. - If a neighboring tag receives information regarding the next wake-up time for reception, that tag may adjust its wake-up schedule to transmit an additional tag report at that time and enable the tag to receive this additional tag report during the next wake-up time. - If the gNB receives information regarding the next wake-up time for reception, the gNB may schedule to transmit new tag configuration data, a tag "paging" request, or other messages indicating DL data for the tag at the next wake-up time. · If the tag is then detected by a different gNB, thus indicating that the tag has moved to a different cell coverage area during the tag's sleep cycle, the gNB that had scheduled the transmission may cancel the transmission scheduled for that tag. - If the gNB receives information regarding the next wake-up time for transmission, the gNB may schedule cellular communication traffic UL / DL such that sufficient resources are available in the next wake-up time slot, enabling the tag to be transmitted with little interference from other UL / DL traffic. · If the tag is detected by a different gNB, thus indicating that the tag has moved to a different cell coverage area during the tag's sleep cycle, the aforementioned gNB may cancel the reception scheduled for that tag. Instead, the aforementioned gNB may, for example, use the time slot for other purposes or maintain the time slot to listen for other (potential) tags that may use this time slot in the future. · If the SL-UE receives information regarding the next wake-up time for transmission, the SL-UE may configure itself to listen for any transmissions of the tag at its designated wake-up time. If it receives such a transmission, the SL-UE may report it to the location information service or its gNB. The form of this information may include the following. - An indicator of the time delta, or a future time slot (e.g., a timestamp / SFN number / UTC time value, or a part thereof). - Energy / power harvesting status information that the receiver (e.g., the gNB) can use to accurately or approximately estimate the next wake-up time of the tag.

[0208] Private Configuration of Tag Reception Time Window by gNB In one exemplary embodiment, the gNB may privately configure the time window of the tag to change, extend, or replace the default calculated reception time window. This may be performed using private (security-protected) unicast communication with the tag. The gNB may perform this for tag T to enable the tag T to more appropriately receive tag reports from neighboring devices that may send tag reports at a fairly "early" or "late" timing within the time window. Or it may be from neighboring devices of tag T that operate under different gNBs / cells and thus may operate with different configuration information (e.g., a different time window).

[0209] Private Configuration of Tag Transmission Time Window by gNB In one exemplary embodiment, the gNB may privately configure the time at which to send the tag report of a particular tag T, for example, using private unicast communication to that tag T. The purpose of doing this may be to enable faster propagation of tag sightings within the network. FIG. 6 schematically shows an example of the private configuration of the transmission time window of an in-coverage tag T601 (small white circle) by a gNB621 (large circle) according to an embodiment of the present invention. As shown, there are Out-of-Coverage (OoC) tags 611, 612, 613 (small filled circles) that report at random times t = 1, 2, 3 (Tx@t = 1, Tx@t = 2, Tx@t = 3), respectively. The gNB621 sets (cfg) the transmission time of the in-coverage tag T601 to t = 4, so that when this in-coverage tag T601 sends a report message to the gNB621 (unidirectional arrow), this report message is guaranteed to include all tag sightings collected from other tags 611, 612, 613 at times 1, 2, 3. By doing so, a location information service (not shown) can obtain the latest information, and the average latency between the time of sending the tag report and the time of generating the location estimation by the location information service is reduced.

[0210] Ideally, the rightmost tag 613 reports at t = 0 so that the latest tag sighting of that tag is included by the tag 612 that reports at t = 1 (Tx@t = 1). However, unfortunately, in this exemplary embodiment, since the OoC tags 611, 612, 613 are outside the range of the gNB 621, this is not possible. However, this can be solved in various ways. For example, by setting other tags via a relay UE, the in-coverage tag T can also function as a simple relay. Other solutions, especially the solutions as shown below, can be proposed.

[0211] Automatic setting of the transmission time of tag reports to minimize the latency of tag sightings Referring to the example of FIG. 6, by observing the connection state of the tag itself and its neighboring tags, automatic setting of the transmission time of the tag becomes possible. In particular, - If the left tag 601 (illustrated as corresponding to Tx@t = 4) determines that it is within the coverage of the gNB 621, it can schedule itself at a late timing within the time window. - If the two central tags 611, 612 (illustrated as corresponding to Tx@t = 1 and Tx@t = 3) determine that they are OoC of the gNB 621 but there is a neighboring node 601 (illustrated as corresponding to Tx@t = 4) located within the coverage of the gNB 621, the two tags can schedule themselves at the center of the time window. - If the right tag 613 (illustrated as corresponding to Tx@t = 2) does not find a neighboring tag within the coverage of the gNB 621 and determines that it is outside the coverage of the gNB, it can schedule itself at an early timing within the time window. Such in-coverage / out-of-coverage status may be inferred by the tag by including the following related status bits in the public data section of the tag report. - in-gNB-coverage-bit: Set to '1' by the tag only when within the gNB coverage. - in-coverage-neighbor-bit: Set to '1' only if at least one neighboring tag reported 'in-gNB-coverage-bit = 1' during the previous time window.

[0212] As a result, tag report messages from a distant (i.e., rightmost) tag (e.g., 613) are propagated faster by the gNB (e.g., 621), thereby reducing latency and obtaining a more up-to-date position estimate of the tag (e.g., 613). For example, if the tag reports every hour, in this example, assuming the tag normally maintains the same randomly selected time slot within the time window, depending on the randomly selected transmission time of the tag, the tag sighting of the rightmost tag (e.g., 613) will always be one hour old or two hours old when received by the location information service. In fact, in the example of the rightmost tag 613, depending on the scheduled time and the three-hop propagation of the tag report from tag 613, it can be zero, one, two, or three hours old. By applying this exemplary embodiment, the tag sighting can always be approximately zero hours old (or a few seconds in some cases) when received by the location information service.

[0213] Including a hop limit or hop count in the tag report In one exemplary embodiment, the tag report message may include a hop limit value or a hop count value within the public data section. This allows the tag to determine not to forward the tag report in the form of a tag sighting to other tags / UEs, for example, when the hop count value has reached a pre-set threshold or the hop limit value has reached zero. This provides the advantage of improving efficiency as certain tag reports will not be resent for a long time or multiple times. Another advantage is that if the hop count / hop limit information is included in the tag sighting, the location information service may be able to more accurately estimate the position of the tag.

[0214] Including a "need-forwarding" bit in the tag report In an alternative or additional exemplary embodiment related to the above hop limit / hop count function, a "need-forwarding" bit may be included in the tag report. When set (1), the tag report may be forwarded to other tags / UEs as a tag sighting. When not set (0), the tag should not include it in the tag sighting, and only the gNB collects this tag report and reports it to the location information service as a tag sighting. A hop limit value equivalent to this bit (which varies depending on the protocol rules used, for example 0 or 1) may be used as an indicator indicating "no forwarding required" (i.e., the tag report is not forwarded) when hop-limit = 0, and "need forwarding" (i.e., the tag report may be forwarded again) when hop-limit = 1.

[0215] Priority value included in the tag report In one exemplary embodiment, the tag report may include a priority value (e.g., 2 bits) within the public data section. This has the advantage of helping the tag that sends the tag sighting to prioritize the tag sightings included in the tag report. For example, the tag can include the maximum number of tag sightings that fit within a specific tag report target size (in bytes), putting the most prioritized tag sighting first, then the next less prioritized tag sighting, and repeating this until the target tag report size is reached (or exceeded if including a new tag sighting) or until there are no more tag sightings to include.

[0216] Selection of tag sightings to report In one exemplary embodiment, the tag can report or send some or all of the plurality of tag sightings to nearby nodes (e.g., gNB or other tags) as part of the tag report. If there are too many tag sightings to report within a limited time window, or if the energy budget of the tag is limited, the tag may use a policy to select the tag sightings to report. A particular option in this embodiment is not to report tag sightings that have already been reported at least K times by other nearby tags. Here, K is a configurable or pre-defined parameter or threshold. If at least K tag sighting reports have already been confirmed from neighboring tags, the tag suppresses new reports about that tag sighting. Another policy may be to suppress reports of old tag sightings and prioritize new sightings that still need to be reported. The determination of old tag sightings may be made based on the timestamp value in the corresponding tag report and / or the local time of the tag that recorded the tag sighting. The latter may typically be the same as the reception time of the corresponding tag report. Reports not selected / transmitted based on the selection policy may be discarded or sent later.

[0217] Another embodiment of the selection is to use a priority value as described above. Such priority-based selection may be combined with the selection of tag sightings based on the tag sighting age described above, or with other criteria for selecting the most relevant tag sightings.

[0218] Direct additional transmission of tag sightings to the gNB In one exemplary embodiment, the in-coverage tag can periodically connect to the gNB and transmit the tag sightings collected so far via a normal (e.g., 5G NR) Uu uplink connection. This periodic connection may be performed at a lower frequency than is feasible to reduce the energy consumption of the tag, but may be useful in the following scenario example. - A large number of tag sightings that do not fit into a normal tag report have already been collected by the tags (e.g., because the capacity to accommodate tag sightings is limited). - The tag must somehow connect to the gNB, for example, to send sensor data, to check the feasibility of firmware updates, to check configuration updates, or to update the firmware. - Although the tag sightings already collected for tag reports are not transferable (e.g., because they are marked as "not transferable" or because the hop - limit = 0), it is still useful to report them to the gNB.

[0219] Once connected to the gNB in this way, the tag can report all tag sightings still remaining in its internal storage, including those that were already included in a tag report. Alternatively, to reduce the time and / or energy used for transmission, tag reports can be selectively included (e.g., only tag reports not yet transmitted within a tag report, or only the most prioritized tag sightings, etc. are reported, and optionally, a method similar to one of the selection methods for selecting tag sightings within the tag reports described in the present invention is used). Depending on the implementation form of the tag, after reporting the tag sightings to the gNB via a dedicated UL connection, the tag may delete some or all of the tag sightings.

[0220] Protection of Tag Sightings Reported in Tag Reports In one exemplary embodiment, the tag can protect the reported tag sighting in order to avoid false reports or forgeries related to the tag report containing the tag sighting information. Such "malicious" reports or forgeries can be caused by a gNB attacker, a tag attacker, or another type of on-path attacker (e.g., a UE, or a compromised device within the RAN or CN). An example of forgery is that Node N1 receives a genuine tag report from tag T1 and adds this tag report as a tag sighting of tag T2, suggesting falsely that it is T2 rather than N1 that received the tag report from T1. However, if T1 and T2 can "digitally sign" the tag sighting, it becomes much more difficult to carry out this type of attack. Thus, an example of a solution can include transmitting a tag report with a payload embedded according to the following relation. tag-report={timestamp,tx-power,payload,H(tag-temp-id|timestamp|tx-power|payload)} (11) Here, the "payload" part can be one or more concatenated tag sightings. The hash function H(.) can prevent forgery when the tag report itself is transferred in a form embedded within the tag report by showing that the tag sighting by the tag is legitimate. Although not included in the above relation (11) of this exemplary embodiment, in the case of other exemplary embodiments, a "config-data" item may also be included.

[0221] Using the digest (summary / hash) form of the tag sighting The above-mentioned "payload" part may have a fairly long size if it includes a tag sighting with complete "secure section data", and may be even longer when using a tag sighting with complete "tag report" data. In an exemplary embodiment, instead of a complete tag sighting, the tag can also report a summary / digest tag sighting, which is a tag sighting encoded as a shorter version of the complete tag sighting. For example, without changing other data elements of the tag sighting, only the digest (shorter) version of the secure section data may be included. Alternatively, it may consist of a digest (shorter) version of all the data elements of the tag sighting. Note that the digest of the secure section data may potentially be substantially equivalent to the digest of the tag report.

[0222] This allows the tag report transmitted by the tag to contain more tag sightings packed into the same space if at least one tag sighting is included in digest form. However, this will not work if all tags report digest tag sightings instead of complete tag sightings for all tag sightings. This is because in that case, the location information service has no way to reconstruct the original tag sighting data associated with the digest form. Therefore, at least one complete (i.e., not a digest) tag sighting needs to be sent to the location information service (without being lost in the process of reaching the location information service). If such one complete version of the tag sighting is received by the location information service, other tag sightings containing exactly the same data (either entirely or partially, for example, only the secure section data exactly matches and other fields may be different) can refer to digest tag sightings instead of complete tag sightings, and the location information service can still appropriately use these digest tag sightings as if they were complete tag sightings.

[0223] Note that some information will necessarily be omitted by using a digest instead of the full version. Therefore, there is a risk that the digest may not be uniquely correlated with the tag sighting with 100% certainty. This is similar to the case of using a hash to represent information, and no matter how small the probability is, there is always a possibility of a hash value collision. To reduce this risk of collision, the digest can be selected to have a sufficient number of bits (e.g., a hash) such that the probability of collision with other tag sightings generated within the same cell / area during a specific same period (e.g., a day or a time) is very small (e.g., <0.0001%). The digest (e.g., a hash value) does not need to be unique over a wide area such as a country, a continent, or the whole world, nor does it need to be locally unique over a long period (a day, a week, or more). Therefore, the length of the digest can still be kept relatively short, realizing the advantages of reducing the size of the tag sighting and / or including more tag sightings in the tag report.

[0224] To achieve the feature that in addition to receiving the digest of the same tag sighting, at least one full tag sighting is received by the location information service so that the digest can refer to the full tag sighting with a high probability, specific rules / strategies may be required regarding the transmission of the digest and the full version of the tag sighting. Therefore, the rules / strategies considered to achieve this may include at least one of the following. - A tag can report the digest of the secure section data within the tag sighting only if the same secure section data has been confirmed at least N times to be included in the tag sightings of other in-coverage (peers) tags (where N is a configurable or pre-defined value (e.g., N = 3)). - The timestamp of the tag sighting may be used as a digest, or as part of a digest, and may function as a unique ID of the tag sighting within a certain local area. This local area may consist of the area of the tag that reported the tag sighting and the area of the tags in the immediate vicinity. - The first N bytes of the secure section data and / or a short hash (e.g., 24-bit or 32-bit) of the secure section data may be used as a digest. - A coverage-out tag can start using the digest of a specific secure section data within its tag sighting only when it has verified that at least M other neighboring tags within the coverage of the gNB are using the digest form of the secure section data in the tag sightings they reported (where M is a configurable or pre-defined value (e.g., M = 1)). At the same time, a coverage-in tag starts using the digest of the secure section data after obtaining some confirmation that the gNB has received the full version of the specific secure section data embedded in the tag sighting data element. Such confirmation can be implemented in various ways, for example, by reporting the tag sighting to the gNB (either by the usual method of broadcasting within the tag report or by using a dedicated unicast connection to the gNB), or by obtaining a confirmation message from the gNB regarding the receipt of the tag sighting. The confirmation message from the gNB may be sent by the gNB in the same format as the tag report sent by the tag during the next time window, where the gNB includes the digest of the specific secure section data within the tag sighting data structure as an indicator that it knows this specific secure section data. Alternatively, the confirmation message may have some other specific format different from the defined tag report structure, such as a simple positive acknowledgment message that confirms the receipt of a previous transmission of the tag or set of tag sightings.

[0225] In certain exemplary embodiments, where digest values are reported for tag sightings but the corresponding complete secure section data cannot be found, the location information service may issue a request to perform a "paging" operation on one or more gNBs, and request that the gNBs report the complete version of that tag sighting to tags that still hold the complete tag sighting of this secure section data digest. Such a "paging" operation can be implemented by making a temporary change to the configuration data, for example, by extending the length of the "config-data" field by adding a bit string that encodes the ID of the requested secure section data digest. This encoding may consist of, for example, the complete digest form of the secure section data, or may consist of a shorter form, such as the digest of the digest.

[0226] Configuration data including pre-defined target parameters for tag sightings to be included in the tag report In one exemplary embodiment, the "config-data" item may include a setting or pre-defined numerical value indicating the preferred or maximum number of target tag sightings to be included or embedded in the tag report. This allows the RAN to find a trade-off between the efficiency of the tags (i.e., power on the tags is conserved as the transmitted message becomes smaller) and the quality of the available information (i.e., the number of tag sightings available for reconstructing the tag's position with higher accuracy and reliability increases). For example, the pre-defined number of target tag sightings may be a 4-bit value that directly encodes the target number of tag sightings 0 to 15, which is preferably included in the tag report message. Alternatively, it may be a 3-bit value indicating one index 0 to 7 of a pre-defined look-up table whose table value determines the pre-defined number of targets. Optionally, if there are more high-priority tag sightings and they exceed the pre-defined number of targets, the tag may still decide to report these high-priority sightings.

[0227] In one exemplary embodiment, the "config-data" item may optionally or additionally include settings or predefined values that indicate the target size (e.g., number of bytes) of the preferred or maximum tag sighting to be included or embedded in the tag report.

[0228] In another exemplary embodiment, the "config-data" item may optionally or additionally include settings or predefined values that indicate the target number of the preferred or maximum digest and / or full version tag sightings to be included or embedded in the tag report.

[0229] Handling of gNB Cell Boundaries If there are multiple nearby cells, there may be problems related to time synchronization. FIG. 7 schematically shows an example of an OoC situation in a location information system having two cells. In the figure, coverage tags 701, 702, 703, 704, 705 and out-of-coverage tags 711, 712, 713 represented by small circles are distributed through two cells. Similar to FIG. 1, tags 701, 702, 703, 704, 705 represented by small white circles can transmit RF signals, and these RF signals can be received by the nearest anchor nodes 721, 722, 723, each represented by a large circle and distributed through two cells. Tags 711, 712, 713 represented by small filled circles are OoC and cannot directly transmit to any of the anchor nodes 721, 722, 723, but can communicate with nearby tags (e.g., 701, 702, 704, 705), as shown by the bidirectional arrows connecting these tags. Assuming that one or more gNB antennas in a cell (e.g., cell 1) broadcast configuration information for determining the active time window of a tag, there may be another gNB that determines different time window information for another nearby cell (e.g., cell 2). In such a case, tags 704, 713 located between the two cells 1, 2 (i.e., tags near the dotted line) may have a problem that they cannot communicate with in-range tags 702, 703, 711, 712 (e.g., those located in "cell 1") within the range of the other part when synchronized with the time schedule of the tags 705 / anchor node 723 of one part (e.g., those located in "cell 2") (and vice versa). The inability of the tags in cell 1 to communicate within the time window shared with the tags in cell 2 is indicated by the dotted arrow with the symbol "?". Therefore, when two cells 1, 2 set different time windows, the transmission windows and / or reception windows of these nearby in-range tags are "offset" in time, and when the two cells 1, 2 set different frequency resources for the tags, they may also be "offset" in frequency.

[0230] In one exemplary embodiment, in the border regions of multiple different (e.g., N) gNBs / cells, there may be different RAN configurations for each of the participating gNBs / cells for tagging. In particular, different time windows may be defined such that tags within the border region cannot receive each other's tag reports distributed in areas within the coverage of the cells (as shown by the two cells in FIG. 7). To improve the accuracy and reliability of the position estimation of all the tags involved, it is beneficial for these tags in the border region to be able to normally send tag reports to all neighboring tags regardless of the configuration differences. In fact, the larger the number of neighboring tags, the higher the position estimation accuracy, the stronger the evidence that the tag was present at a specific location at a specific time, and the more effectively the coverage area in which the system operates is improved.

[0231] In a particular embodiment, the tag may be configurable with N sets of configuration data (typically, N = 2 or N = 3). For example, when N = 2, the tag may apply both configurations and monitor two time windows while both configurations are active. In one example, the tag may identify these two configurations by observing different nodes within the area that broadcast different configurations. These different nodes may be, for example, gNBs, relay UEs, general NR SL SyncRef UEs, or peer tags. If there are too many competing sets of configuration data, the configuration data sent by the gNB may be prioritized over the configuration data sent by any other node.

[0232] In another specific embodiment, one gNB may also be able to send the configuration data of nearby other gNBs / cells so that tags located near the cell boundary can be utilized. In that case, the tag can detect that it is located near the cell boundary by briefly trying the time window of the second configuration data and counting the number of tag sightings during this additional (second) time window. When the number of sightings exceeds a pre-defined threshold T, the tag knows that it is located near the cell boundary and continuously monitors the additional time window as well. Otherwise, the tag may stop monitoring this additional time window or monitor the additional time window sparsely. Sparsely monitoring is beneficial because it reduces the energy consumption of the tag compared to continuously monitoring the additional time window. Note that due to the displacement / movement of the tag, the tag may later move towards the cell boundary or, in some cases, into the coverage area of a second gNB / cell. In that case, it becomes appropriate to apply the additional (second) configuration data again. For this purpose, the tag may use available sensor data (e.g., data from a motion sensor) as a criterion for determining whether to perform monitoring when the next occurrence of the additional time window arrives.

[0233] In another specific embodiment, the same time window but different frequency channel settings are configured for neighboring cells, so that all tags can use the same time window even if they are located at the cell boundary. However, the overall flexibility of the system to adjust the time window according to the current number of active tags decreases. Such second configuration data that only differs in frequency can be efficiently encoded using only one additional (second) field called "frequency / channel", and this field can be included in or added to the "config-data" item of the tag report.

[0234] In another specific embodiment, the configuration data may include a "time shift" parameter, and when this parameter is non-zero, a second setting that activates the tag by applying a time shift to the time window can be indicated. This has the advantage of being able to encode the second data set very efficiently. Therefore, this can be regarded as a specific sub-case of the case where N = 2 for the above-mentioned multiple different settings. Similarly, in the case of N = 3, there may be a second time shift parameter. Also, by encoding variable-length time shift arrays of lengths L = 0, ···, K, multiple configuration data sets (each 1, ···, (K + 1)) with only different relative arrangements of time windows can be encoded respectively. In an exemplary embodiment, two adjacent gNBs can adjust the configuration data so as to be able to efficiently encode a simple "time shift" or "frequency change" in the "configuration data" of both cells served by these gNBs (or located within the coverage of these gNBs). An example of realizing N (= 2) different time windows that reuse the same time window duration and the same frequency / channel with a single configuration data is as follows. - Frequency / channel selection: 8 bits. - Selection of the position of the time window: 8 bits. - Selection of the duration of the time window: 4 bits. - Selection of the shift of the time window: 4 bits. · The value 0 indicates "no time shift", that is, the second or additional configuration data set is not active.

[0235] The RAN adjusts the time window setting according to the tag density In one exemplary embodiment, during operation, the RAN may adjust the "config-data" settings to accommodate necessary changes, e.g., due to changes in the density of tags within a geographical area of interest. For example, in Table II above, if the RAN gNB observes that N tags within the coverage of the gNB consistently exceed the "target duration" of the time window defined in relation to the optional settings of the time schedule parameters of the "config-data" structure, the gNB may select a new time window setting that allows for a longer time window. Such setting changes may be coordinated by multiple gNBs of the RAN. Conversely, if the activity level of tags within the geographical area of interest is low, the "target duration" of the time window may be shortened by the gNB of the RAN. In that case, the change in the setting data may be logged and retained by the RAN gNB performing the observation and may additionally be reported to the location information service. The location information service may use these setting data values for tag report verification. In these examples, one or more gNBs, or the RAN management function, can determine the new settings ("config-data"), which may be achieved through negotiation between the gNB / RAN and the location information service, or the location information service may determine using only the status report and / or operation constraint data from the gNB / RAN as input data for making this decision.

[0236] The location information service identifies the true tag ID from the secure section data In one exemplary embodiment, the location information service may receive a number of tag sightings that include secure section data. These secure section data fields are embedded within the tag sightings that are generated and / or reported by nodes within the cellular network that report the tag sightings (either directly or indirectly) to the location information service. These tag sightings are generated, for example, by a gNB, an SL-UE, a tag (e.g., an in-coverage tag that reports to the location information service via UL unicast via the gNB), or other UEs that can receive tag reports. Note that according to the present invention, a tag sighting may include one or more other tag sightings (e.g., as an embedded data field) or may refer to (e.g., by a digest, hash, timestamp, etc.). In certain implementations, a tag sighting can include a complete tag report message, and this tag report message may embed one or more additional tag sightings that include secure section data fields. As a result, the location information service can identify the true tag ID that created the original of this data for a given secure section data by calculating (or computing) the cryptographic function F(.) for all known tag temporary IDs that are presumed to be located within or previously located within the geographical area of interest until a tag is found where the data of the result of the cryptographic function F(.) of relation (3) matches the secure section data. For status bits, the location information service may also need to try all possible combinations (in an exhaustive manner), possibly in combination with the above loop for all known tag temporary IDs. As an optimization, the location information service may first try the combination of status bits reported last, assuming that the status bits have not changed in the meantime. If the status bits do not change regularly, there is the advantage that the amount of computation that the location information service has to perform on average is reduced.

[0237] The items "tag-temp-id" and "status-bits" within the function F(.) of relational expression (3) are included in the cryptographic calculation but are not transmitted via the wireless communication channel. Therefore, the location information service has to spend resources to try all possible combinations, for example, thousands to millions of known tag-temp-ids within a specific target area (which can be defined, for example, as a gNB / cell coverage area or an intersection area of two or more gNB cells). Due to the progress of computing technology (such as a cloud specially designed for efficient hash / cryptographic bulk operations like those used in blockchain), the location information service can execute such calculations efficiently. Note that there may be a large number of candidate tag-temp-ids. Depending on the situation, since the update of location information may be relatively slow (for example, several tens of minutes or several hours) to save the energy of the tag, the latency of the calculation by the location information service within seconds or minutes may be acceptable.

[0238] In this specific example where the location information service cannot decrypt a specific tag report, the location information service may send these tag reports to other location information services and utilize, for example, one location information service of another operator covering the same geographical area or one location information service in the neighboring area. This has the advantage that the accuracy and reliability of the location estimation of the received location information server may be improved.

[0239] Use of 5G-NR ProSe Open Detection Message In an exemplary embodiment based on the use of 5G-NR ProSe Open Detection Message compliant with 3GPP (registered trademark) TS24.554 (Release 17), the tag may send a detection message in the role of an announcing UE. The message is not encrypted at the ProSe layer but may be integrity protected using a message integrity check (MIC). The MIC can be calculated based on a key derivation function (KDF) using the configured detection user integrity key (DUIK) as an input.

[0240] DUIK may be set for each tag, similar to tag-temp-id. Optionally, the tag-temp-id may be derived from DUIK, or in some cases, DUIK may be selected to be the same as tag-temp-id. Optionally, a monitoring UE that receives a ProSe detection "announcement" message may verify the message using core network ProSe-related services. This may function by reporting the receipt of the detection message according to 3GPP (Registered Trademark) TS24.554 (Release 17). The tag may optionally function as a full monitoring UE as defined in 3GPP (Registered Trademark) (e.g., 3GPP (Registered Trademark) TS24.554 (Release 17)), or the tag may implement a subset thereof. Another (sidelink) UE that is not a tag may function as a monitoring UE.

[0241] The MIC of the detection message can be considered part of the tag report message sent by the tag. In that case, the MIC is included within the tag witness, enabling the relevant network services (e.g., ProSE function or location information service) to verify the MIC of each tag report it processes. Note that this network service may have access to the DUIK set for each tag (e.g., locally, or through interaction with the DDNMF, or by other means), and thus may be able to verify the MIC.

[0242] The above exemplary embodiment can be described with reference to the detection message flow of FIG. 6.1.3.3.1-1, "Integrity Protection of Transmission Code" in 3GPP (registered trademark) TS33.503 v15.0.0. In the case of a UE that announces a tag, it is assumed that steps 1 to 4 are executed only once (while within network coverage), not every time. In the case of a monitoring UE that wishes to verify a tag report by the network, this can be done using steps 11 to 15. The DDNMF is involved in key assignment, and an interaction between the DDNMF and the LMF may be required to assign the appropriate key to be used by the tag.

[0243] Tag paging In an exemplary embodiment, an entity may determine that it does not have, or has but is not accurate enough, the most recent location data of a particular tag it is interested in. This entity may be the location information service itself or a client of the location information service. This embodiment enables the transmission of a specific request or "paging message" to obtain newer and / or more accurate location information of a particular tag of interest. This can be achieved by triggering more tag sightings or tag reports for that tag. This may be a normal cellular paging message (e.g., as defined in 3GPP (registered trademark) TS38.300) adjusted / extended for this purpose, or a paging message for low-power tag operation (e.g., a collision signal for backscatter communication that may include / modulate information fields related to paging in the signal), or a wake-up signal described in other embodiments.

[0244] This embodiment begins by identifying the current active tag-temporary ID of tags of interest (e.g., by receiving from a client, or proactively by itself, or driven (e.g., by a service level agreement (SLA) with a customer of the tag)). This tag-temp-id can then be used as input to a one-way function F(.) for encryption, along with at least one other input known to both the location information service and the tag. Some examples are shown below. - Paging-id=F(tag-temp-id,other-data) - Paging-id=F(tag-temp-id,other-data,salt) - Paging-id=F(tag-temp-id,salt)

[0245] If the "salt" item is used, it may be sent along with the Paging-id. However, the tag-temp-id is not sent by the location information service. This paging ID can be sent to one or more gNBs within the area where the tag was last confirmed and / or within the area where it may have moved based on the prediction of the tag's mobility. The gNB can then include this paging ID information in an additional tag report that it sends so that all tags within the service area can receive it. Alternatively, the gNB may send an additional message of a different type / form than the tag report, and this additional message can be received by the tag within a time window, similar to the tag report.

[0246] The tag that has received the paging ID tag report can confirm whether it is addressed to itself by calculating the function F(.). Note that if the "salt" item is not used, the paging ID may be pre-calculated. When a tag is paged, the tag may send at least one new tag report. Optionally, this new tag report may include a "was-paged" bit set to 1 within the public data section, or a priority field set to the value "high". This allows other tags that witness the tag to know that they should report this tag report to the gNB within their respective tag reports and / or include this tag report with high priority within the tag witness reported to peer tags.

[0247] Optionally, the tag may implement security measures to avoid a battery depletion attack where an attacker sends a large number of meaningless paging requests to the network and forces a large number of additional processing actions on all tags that receive such paging requests. For example, the number of paging requests may be limited to a maximum of N per unit time.

[0248] Optionally, the paging message may include flags indicating that the tag is requested to send specific information, such as a flag indicating that the tag is requested to send updated location information, a flag indicating that the tag is requested to retransmit location information, or a flag indicating that the tag is requested to send information of a specific sensor. Optionally, the paging message may include one or more thresholds of the requested information indicating the minimum and / or maximum difference in values since the information was last requested by the tag device (e.g., if the device is still within a minimum distance from the location last transmitted by the tag, the device does not need to send location information to the network, and if the device is located outside the minimum distance from the location last transmitted by the tag, it indicates that the device needs to send location information to the network).

[0249] As an option, the paging message may include a time value indicating the time when the position of the tag or other data (e.g., sensor data) was last updated / received by the network, and / or the original timestamp of the position or other data provided in the tag report message. The tag may use this information to determine, for example, whether the position information or other data (e.g., sensor data) has changed or sufficiently changed (e.g., exceeded a specific minimum value) since the network last received the position information or other data from the tag, and then decide whether to send its own position information or other data (e.g., sensor data) to the network.

[0250] Optionally, the paging message may include the position information or other data (e.g., sensor data) last received from the tag. The tag may use this information to determine, for example, whether the position information or other data (e.g., sensor data) has changed or sufficiently changed (e.g., exceeded a specific minimum value) since the network last received the position information or other data from the tag, and then decide whether to send its own position information or other data (e.g., sensor data) to the network.

[0251] Tag paging using the System Information Block (SIB) In an alternative exemplary embodiment of the tag paging embodiment described above, tag paging may use an SIB (e.g., defined in 3GPP (registered trademark) TS38.331) extended for this purpose, for example, by adding information elements or defining a new SIB type having the same / similar content as the paging message described above. In another alternative embodiment, the Wi-Fi beacon or probe response is adjusted / extended for this purpose by adding information elements having the same / similar content as the paging message described above.

[0252] Tag paging using the ProSe model B detection message In an alternative exemplary embodiment of the tag paging embodiment described above, tag paging can utilize a restricted (non-open) ProSe model B detection message. In that case, the entity performing the detection can send a protected detection request message containing specific parameters. A matching tag can respond with a detection response message only if it can properly decrypt the request and the tag ID matches the "paged" / requested tag ID, i.e., the same "tag-temp-id".

[0253] Indirect tag paging, or the "Have you seen this tag?" concept In an exemplary embodiment, instead of simply paging the tags of interest as described above, for all tags, information regarding specific tags that are still stored but have not yet been reported for some reason (e.g., due to the selection process of tag sightings included in the tag report, where specific tags have been excluded from some or all of the tag reports) can be requested to be reported.

[0254] For this purpose, the location information service may create a paging request that includes an identifier of the most recent tag report or tag sighting that the location information service wants to know more about. This identifier of interest may be, for example, any of the following. - The first N bits of the tag report. - The first N bits of the secure section data. - The (truncated) hash of the tag report. - The (truncated) hash of the tag sighting. - The digest of the tag sighting. - The (truncated) hash of the secure section data. - The timestamp of the public data section of the tag report. - Combinations of these.

[0255] It is desirable for the identifier to be as short as possible. In one exemplary sub - embodiment, variable - length identifiers may be used. The longer the identifier, the more likely it is to uniquely match the intended tag report, for example, using a Bloom filter data structure.

[0256] Similar to each of the above - described tag paging embodiments, the location information service sends a request to the target gNB, and these gNBs may distribute the paging request to tags within their respective service areas or broadcast a system information block that the tag can receive directly and / or indirectly (e.g., after each received system information block is transferred by the tag to one or more other tags (e.g., in the same way as in ProSe / sidelink relay and / or when transparently transferring the system information block)). Tags that receive this request and for which a matching tag report (which may be the most recent or slightly older) and associated tag sighting metadata are still buffered will include the tag sighting in the next tag report that is preferentially sent to the gNB (or generally broadcast as a tag report in the form to the gNB or other tags). This allows the gNB to receive more tag sightings for this particular tag report, and thus the location information service can more accurately estimate the location and / or past locations of the tag of interest. Also, if the tag of interest acknowledges the paging request, or if it acknowledges that its old tag reports are being sent by other tags, or a combination thereof, the tag of interest may immediately send a new tag report with, for example, a higher priority than normal (as described above, the tag report may include a priority value (e.g., 2 bits) within the public data section). This allows the location information service to obtain newer location data for the tag of interest, separate from the old tag reports requested to more accurately reconstruct the current location of the tag and the possible movement trajectory it may have followed to reach that location.

[0257] Note that the tag does not use any identification information within the tag report, so other tags cannot establish the true ID of the tag that sent the tag report. Therefore, the "Have you seen this tag?" concept necessarily functions by requesting other identifiable information (in this case, the tag report or tag sighting referenced by the identifier) rather than requesting a specific tag ID (e.g., "tag-temp-id").

[0258] In additional exemplary sub - embodiments, the location service can request a specific timestamp value or timestamp range within a paging request to collect data regarding a specific tag report that was lost, or for which sufficient tag sightings were not collected, or to collect more data. For example, if tag T reported at times t = 123, 178, and 181, the location information service may conclude that some tag reports of T are missing during the period t = [124, 177] and page for tag reports within the range 124 - 177. In another example, if the timestamp t within the tag report is encoded as a sequence number (counter), and the location information service has tag reports with t = 123, 125, 126, the location information service may page for any tag reports with the missing sequence number t = 124.

[0259] In an optional embodiment, the tag can implement security measures to avoid a battery depletion attack where an attacker sends a large number of meaningless indirect paging requests to the network. The number of such requests may be limited to a maximum number N per unit time, where N is a pre - set value (e.g., if the unit time is 10 minutes, N = 2).

[0260] A tag that functions as an NR sidelink SyncRef UE instead of an SL - UE or a relay UE In one exemplary embodiment, some tags having higher capabilities (e.g., larger battery capacity, or energy supply from an environment (e.g., sunlight) over a specific period) may function as NR sidelink SyncRef UEs and assist other nearby tags that are OoC to synchronize. By providing the SyncRef signal, these SyncRef tags do not need to function as a full sidelink UE (i.e., SL-UE) or relay UE (see 3GPP™ TS38.331 (Release 16)). Although no special changes are required to provide the basic SyncRef UE functionality, a simplified / low energy consumption SyncRef UE approach may be needed compared to the currently defined 3GPP™ approach for the tags to function as NR sidelink SyncRef UEs while maintaining low energy consumption and / or low cost hardware properties. The SyncRef-enabled tags can automatically turn on / off the transmission of the NR sidelink synchronization signal (or corresponding simplified / low energy consumption synchronization signal) based on the local availability of other SyncRef UEs and the internal availability of sufficient energy to operate as a SyncRef UE.

[0261] In summary, this specification describes a system and method for managing and configuring a communication device within a cellular communication network having a location identification function, the communication device reporting the location of the communication device to a location information service in cooperation with other communication devices. In particular, the present invention is directed to a tag that can be a low-power and low-complexity communication device. Active time window synchronization can be provided so that the tag can "sleep" most of the time to conserve energy. Privacy and security of the data reported by the tag are achievable. Each tag can report its ID through the calculation result of an encryption function, and only the location information service can derive the actual / true tag ID by combining all the collected tag reports (obtained from, for example, a security-protected database) with the knowledge of the tag identifier. Reports from tags outside the coverage can be relayed by tags within the coverage, thereby improving the overall reliability and expanding the coverage area where the location information service can be provided.

[0262] The overall system operation for a particular tag can be summarized as follows. - The tag periodically transmits a security-protected tag report (report message), e.g., via an SL detection message. - The tag report is collected by nodes such as the collecting gNB, and / or the collecting "tag" UE, and / or the collecting SL-UE, and / or other collecting UEs that do not use SL if the present invention is implemented using a wireless interface of a type other than "SL". The collecting UE collects the tag report by creating a tag sighting (observation report) that includes metadata regarding the received tag report, and directly reports the tag sighting to the location information service or reports it to a gNB within the coverage area, and this gNB forwards the received tag sighting, including the tag sighting generated by itself, to the location information service. · A collecting (tag) UE outside the gNB coverage may include a tag sighting in its own tag report transmitted to neighboring tags. · The collected (tagged) UEs within the gNB coverage may include tag sightings in certain cases, for example, may include a digest of the tag sightings, which may inform the OoC UE that it may start using the digest version of the tag sightings henceforth. - The location information service extracts / estimates the location and / or location trajectory of each tag based on the combined location of the collecting nodes that reported, including both the collecting gNB and the collecting UE. · If the collecting UEs have unknown locations (e.g., because those UEs themselves are tags), the location information service may also estimate their locations. Overall, this consists of solving a multi-variable non-linear optimization problem with noisy / sparse data inputs and parameter constraints applied. It may be useful to use a maximum likelihood estimation model to solve this optimization problem. - In that case, the location information service provides information regarding the identified tags and their estimated locations to an authorized client, and each client receives only the information regarding the subset of tags that the client is authorized for.

[0263] Note that even if a tag cannot directly reach the collecting UE or gNB within the coverage itself, other nearby tags may collect the tag report of that tag including the embedded tag sightings and transfer it to any gNB (if possible) or transfer it to the collecting UE within the coverage, which can then transfer it to the corresponding gNB.

[0264] Although some embodiments of the present invention are described based on the location of the tags, it should be noted that other uses of the tags are not excluded. The characteristics of the tag may be obtained by reading the tag. This characteristic may include the ID of the tag. If the base station to which the ID of the tag is delivered is known, it may be possible to infer the (approximate) location of the tag. The characteristic may also include the type of the device, or the device type indicating the type of the device / product to which the device is attached.

[0265] Although the present invention has been illustrated and described in detail in the drawings and above, such illustrations and descriptions should be considered illustrative or exemplary and non-limiting. The present invention is not limited to the disclosed embodiments. The proposed embodiments can be implemented in any type of wireless network, for example, devices that communicate using cellular wireless communication standards, specifically the 3GPP (registered trademark) (third generation partnership project) 5G specifications and NR (new radio) specifications. There can be various types of 5G wireless communication devices, for example, mobile phones, smart watches, smart tags for location tracking and logistics, vehicles (for V2V (vehicle-to-vehicle) communication or more general V2X (vehicle-to-everything) communication), V2X devices, IoT hubs, IoT devices (including low-power medical sensors for health monitoring), medical (emergency) diagnosis and treatment devices (for hospitals or first responders), virtual reality (VR) headsets, etc.

[0266] Although some embodiments are described with respect to sidelink communication, the present invention can also be implemented based on existing 5G ProSe functions (for example, those described in 3GPP (registered trademark) TS24.554 (Release 17)) as described below. - A single ProSe detection relay service code (RSC) may be linked to a specific set of detection keys. A specific RSC may determine a specific group of tags that cooperate with each other in location determination, and each tag may have a DUIK_i that is a different detection user integrity key (DUIK). This DUIK_i may substantially serve the role of tag-temp-id, or tag-temp-id may be derived from DUIK_i. Using that specific DUIK_i, the tag can sign the detection message using a message integrity code (MIC) that is MIC_i. - If DUIK_i exists for each tag i, the DDNMF network function can examine all DUIKs related to the RSC and identify the DUIKs that can be used for MIC verification. Note that the current 3GPP (registered trademark) ProSe specification MIC is only 32 bits. If there are a large number of devices (e.g., 2^16 devices) in the group and each device has a different DUIK_i key, it is highly likely that two devices will generate the same MIC at some point. · Therefore, for this purpose, it may be necessary to specify a longer MIC in the ProSe specification or limit the tag group size. · As another option, if a tag ID collision is suspected, the ID can also be verified by requesting or obtaining another detection message from the same tag at a later point. In that case, since MIC_i may be calculated with different UTC timers, MIC_i will be different, and it is expected that the same collision will not occur again, so the actual ID of the device can be retrieved retrospectively. - The problem when using DUIK_i to identify tags is that the monitoring UE receiving the detection message cannot actually confirm whether the tag is genuine. Therefore, it may be necessary to send all detection messages to the CN / position information service for verification, which can be a problem (e.g., the risk of a denial-of-service (DoS) attack). As a solution in that case, it is conceivable to maintain the DUIK for its original purpose defined in the 3GPP (registered trademark) specification, that is, to use a single DUIK associated with the RSC to verify the received message and maintain it for the purpose of having the monitoring UE verify it as the first line of defense against DoS attacks. The tag and the LMF have different unique keys (or the tag-temp_id described in the above exemplary embodiments of the present invention) to create a secure envelope that enables the position information service to verify the ID of the tag. - The confidentiality option for ProSe restricted detection may be used, in which case the detection message may be encrypted. Assuming that all tags within a tag group use the same detection user secret key (DUCK), the tag's tag-temp-id or fixed tag-id may be encrypted using the DUCK. In that case, the LMF may be responsible for decryption, and the DUCK should not be provided to the monitoring UE. Thus, other tags within the group may receive the tag's messages and help forward these messages to the LMF (Location Information Service). - 5G ProSe may specify a number of settings for the UE (e.g., identifiers and keys, etc.), which may make the tag unnecessarily complex and cause the tag to consume more energy than strictly necessary. Therefore, instead of explicit settings during operation, factory / vendor pre-settings of the tag may be considered. That is, a fixed tag-id may be pre-set for the tag, and the tag may continue to send this ID in a secure manner, or send a tag-temp-id securely derived from the tag-id, · The operator can ship them to the customer who is the purchaser in a pre-set state and attach tags to the goods for tracking. The customer can track the tags using their own infrastructure (e.g., their own UE), borrowing the operator infrastructure, or a combination of both. For this, a secure communication channel may be required between the vendor / operator and the customer to communicate the tag-id of the purchased tags, - As an additional or optional solution for obtaining unset tags, the tag may be (re)set using the ProSe detection message, · For example, after purchasing a tag, the owner / operator may send a ProSe restricted detection (Model B) message including new (configuration) parameters of the tag at the vendor's factory or the customer's site. For example, these parameters may include an updated ID (tag-id), or the RSC of a tag group, or other relevant parameters such as key material. The reply to the message may be an affirmative response in the form of a detection message to confirm notification that the new settings have been applied. Therefore, the tag only needs to send and receive detection messages, and it is possible to simplify the tag design and reduce costs without the need to implement other types of communication (such as UL, DL, and ProSE SL direct communication).

[0267] The present invention may be implemented by combining one or more of the above exemplary embodiments using 5G ProSe and exemplary embodiments using non-5G ProSe. In that case, the tag-temp-id ID of the tag may be linked to or derived from, for example, the UE qualification information defined by 3GPP (registered trademark) or the key defined by 3GPP (registered trademark).

[0268] Furthermore, the present invention can be applied to a low-cost and low-power tag tracking system incorporated into an existing cellular network infrastructure (such as 5G, 6G), where the tag may be mobile, static / fixed, or semi-static / semi-fixed.

[0269] In particular, the exemplary embodiments of the present invention can be applied to at least the following fields. - IoT applications (such as smart cities) including low-cost IoT sensor tags embedded in the environment. · The energy required for the operation of the tag may be collected from the environment and / or supplied by a battery that lasts for several years. · Inside mobile products / objects / vehicles for industrial use. - The logistics field for product tracking. · The tag may be embedded in a package or container. · During some periods (e.g., inside a container at sea), location updates may not be very necessary. It may be sufficient to simply confirm that the package remains located near other packages. During other periods (e.g., movement in a logistics center), more frequent location / status updates may be required. · Sensors within the tag may report on the condition of the goods (e.g., temperature, freshness, or shock experienced from movement). · Anti-theft tag. - Indoor location information system. - Hospital logistics for tracking the location of goods, equipment, and personnel.

[0270] Other variations of the disclosed embodiments can be understood and realized by those skilled in the art of practicing the claimed invention from the drawings, the disclosure, and the appended claims. In the claims, the term "comprising" does not exclude other elements or steps. An element in the singular does not exclude a plurality and may correspond to "one or more". The above description has detailed a particular embodiment of the present invention. However, regardless of how detailed the above content is described, it will be understood that the present invention can be implemented in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of a particular term when describing a particular feature or aspect of the present invention should not be construed as meaning that the term is redefined to include the specific features of the feature or aspect of the present invention to which it is associated. Further, when conventional expressions similar to "at least one of A, B, and C, etc." are used, generally such syntax is intended in the sense that those skilled in the art will understand the conventional 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. When conventional expressions similar to "at least one of A, B, or C, etc." are used, generally such syntax is intended in the sense that those skilled in the art will understand the conventional 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. Also, those skilled in the art will understand that substantially any disjunctive word and / or phrase presenting two or more alternative terms in any of the specification, the claims, or the drawings is intended to contemplate the possibility of including one of the terms, any of the terms, or both terms. For example, the expression "A or B" will be understood to include the possibilities of "A" or "B" or "A and B".

[0271] A single unit or device may perform the functions of the plurality of items recited in the claims. Just because a plurality of means are recited in mutually different dependent claims does not necessarily mean that a combination of these means cannot be used advantageously.

[0272] The operations described may each be implemented as program code means of a computer program and / or as dedicated hardware of a test run device or a lighting fixture device. The computer program may be stored and / or distributed on a suitable medium such as an optical storage medium or a solid state medium supplied together with or as part of other hardware, or may be distributed in other forms via the Internet or other wired or wireless communication systems.

Claims

1. A communication device within a wireless network whose characteristics are to be identified, the communication device acting as a node, generating a first secure report message, receiving configuration information directly or indirectly from a base station device, transmitting the first secure report message, wherein the configuration information at least includes information regarding a time window in which the communication device transmits the first secure report message to the base station device and / or other nodes and receives a second secure report message from the other nodes, and / or information regarding frequency resources used by the communication device to transmit the first secure report message to the base station device and / or other nodes and receive a second secure report message from the other nodes.

2. The communication device according to claim 1, wherein transmitting the first secure report message is performed using a frequency resource that depends on an identifier, communication device parameters, or other implicit / explicit indication, and / or within a time window.

3. The communication device receives the second secure report message from one or more other nodes, generates a respective observation report associated with the reception of the at least some second secure report messages in response to receiving the at least some second secure report messages, and selectively embeds the observation report within the first secure report message.

4. The communication device receives a timing reference from a synchronization signal when the communication device is located within the coverage of a synchronization source, and infers a timing reference from the reception of at least one second secure report message from at least one neighboring node among the one or more other nodes when the communication device is not located within the coverage of a synchronization source.

5. The communication device embeds the received configuration information as a configuration data field within the first secure report message.

6. The communication device according to claim 5, wherein the setting data field includes at least a predefined target numerical type for controlling, and / or affecting, and / or limiting the size of the first secure report message.

7. The communication device controls the transmission power for transmitting the first secure report message using a predefined transmission control policy determined based on the received setting information, the communication device according to any one of claims 1 to 6.

8. The communication device according to any one of claims 1 to 7, wherein the first secure report message includes at least a secure section data field that is an output of an encryption function over a plurality of data items.

9. The communication device according to claim 8, wherein the plurality of data items of the secure section data field includes at least a temporary identifier of the communication device.

10. The communication device embeds a payload within the first secure report message, transmits the first secure report message including the embedded payload, and the payload is an output of a locally computed encryption function, the communication device according to any one of claims 1 to 9.

11. Selectively embedding the observation report within the first secure report message selecting, from among the observation reports, the observation reports transmitted previously less than a predefined threshold number of times, and / or selecting, from among the observation reports, newer observation reports, and / or selecting, from among the observation reports, the observation reports not indicated as being transmitted by nodes within the coverage of the base station device, and / or selecting the observation reports marked or identified as having a high priority, and including the selected observation reports within the first secure report message to be transmitted, the communication device according to claim 3, or any one of claims 4 to 10 dependent on claim 3.

12. Selectively embedding the observation report within the first secure report message selecting, from among the observation reports, the observation reports transmitted more than a predefined threshold number of times previously, and / or Selecting an older observation report from among the observation reports; and preventing the selected observation report from being embedded in a first secure report message to be transmitted as part of the first secure report message within the time window, and transmitting the unselected observation reports among the observation reports, the communication device according to claim 3, or any one of claims 1 to 10 depending on claim 3.

13. The communication device is automatically extending the time window when there is no available time slot within the time window and on the transmission frequency channel of the frequency resource, or when the ratio of occupied time slots within the time window exceeds a predefined threshold, the communication device according to any one of claims 1 to 12.

14. The communication device is when the communication device is located on a cell boundary separating a cell within the coverage of the base station device from another cell within the coverage of another base station device, receiving other configuration information from the other base station device, the other configuration information at least including information regarding another time window for the communication device to perform transmission and reception, and information regarding other frequency resources used by the communication device for transmission and reception, the communication device performing conditional transmission in both the time window and the other time window, the communication device according to any one of claims 1 to 13.

15. A method for identifying the characteristics of a communication device as a node in a wireless network, the method comprising: generating a first secure report message; receiving configuration information from a base station device, receiving directly when the communication device is within the coverage of the base station device; transmitting the first secure report message, The method, wherein the configuration information at least includes information regarding a time window in which the communication device transmits the first secure report message to the base station device and / or another node and receives a second secure report message from the other node, and / or information regarding a frequency resource used by the communication device to transmit the first secure report message to the base station device and / or another node and receive a second secure report message from the other node. **Claim 16** A system in a wireless network, comprising at least: a plurality of communication devices according to any one of claims 1 to 14; a plurality of base station devices; and a core network location information service for determining an estimated position of a target communication device among the plurality of communication devices, wherein the core network location information service receives a secure report message transmitted as a unicast message from a communication device among the plurality of communication devices, or directly receives a variation of the secure report message from a base station device among the plurality of base station devices when the base station device receives the secure report message from a communication device within the coverage of the base station device, and the variation of the secure report message is the secure report message embedded in an observation report generated by the base station device or corresponds to at least one secure element of the secure report message.

Images