Low power security feature determination for tags of cellular networks

Abstract

The invention relates to low-power security feature determination for tags of cellular networks. The invention relates to determining features of a communication device (401), including, for example, its identity, its type, the type, location, sensed value, etc. of a product to which the communication device (401) is attached. Specifically, the communication device (401) may be a low-power, low-complexity tag in a cellular communication network with a positioning function that works in cooperation with other nodes (411) to report tag locations to a location service (441).

Description

Technical Field

[0001] The present invention relates to determining characteristics, particularly but not limited to location, of low power devices in wireless networks, particularly but not limited to cellular networks, such as fifth generation (5G) or higher generation networks. Background Art

[0002] In a positioning system within a cellular network or infrastructure, multiple types of devices can participate to provide positioning capabilities. These types may include, for example, tags, powerful mobile user equipment (UE) (e.g., smartphones, V2X connected vehicles, etc.) or infrastructure devices (e.g., fixed and / or mobile gNBs, V2X roadside units, etc.). A tag can be defined as a device whose unknown position is to be determined, and a node can be defined as any device that participates in positioning. Some nodes can act as "anchor nodes" (also denoted as "anchors"), that is, as participating devices whose 2D or 3D position is known to the location system with a certain accuracy, for example, because they never move (e.g., fixed infrastructure nodes), or because cellular positioning technology is used, enabling the cellular network to determine the location of the UE, or because they can use a global navigation satellite system (GNSS) (e.g., the Global Positioning System (GPS)) to determine their position with high accuracy.

[0003] However, there may be situations where the tag is out of coverage (OoC) of the cellular infrastructure. Since nodes in the network infrastructure (such as gNBs) mostly serve as anchor nodes, this means that for these OoC tags, the location cannot be estimated with the required accuracy. Also in the case of low-power tags, due to their very low energy consumption and / or long (battery) life requirements, the transmission of the tag and / or the measurement of the tag cannot be performed continuously, the radio reception (Rx) and transmission (Tx) of the tag cannot be 100% of the time, which makes the communication between such tags and the wireless network infrastructure challenging.

[0004] Furthermore, a low power tag does not transmit as frequently as a normal UE. Therefore, it does not need to be connected to the network all the time. Instead, it can operate in an ultra-low power sleep mode most of the time and only need to wake up to send and / or receive data when there is data to transmit (e.g. new measurements of the tag are ready) and / or when the gNB has data ready to pass to the tag on the downlink. Due to the low cost and low complexity of the tags, it is important to have an efficient wake-up solution that fits the resource constraints of small tags and can scale to a large number of tags.

[0005] For privacy reasons, the tag identity and any location information associated with the tag must not be disclosed to other tags and / or anchors. It is best not to be disclosed to individual infrastructure nodes (such as gNBs), as only authorized and well-protected location services residing in the core network, the cloud, or elsewhere on the Internet can perform the location estimation of the tag and then share this data with the relevant authorized stakeholders and / or services. This is particularly important for a standardized solution where tags from multiple vendors and owners must work with the infrastructure of multiple operators to achieve the common goal of locating the tag. It is important to have a security and / or privacy solution that meets the resource constraints of small tags and can scale to a large number of tags. Summary of the invention

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

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

[0008] According to a first aspect, there is provided a communication device (e.g., a mobile or stationary or intermittently mobile and stationary UE or tag) in a wireless network, wherein characteristics of the communication device (e.g., location, identity, device type, sensed values, etc.) are to be determined and provided. The communication device as a node may be adapted to:

[0009] generating a first safety report message;

[0010] For example, if the communication device is within the coverage of the base station device, then receiving configuration information from the base station device indirectly or directly; and

[0011] Sending the first safety report message;

[0012] The configuration information includes at least information about at least the following items: a time window during which the communication device is suitable for sending a first safety report message to a base station device and / or to another node and receiving a safety report message from other nodes, and / or a frequency resource during which the communication device is suitable for sending a first safety report message to a base station device and / or to another node and receiving a safety report message from other nodes.

[0013] Note that the configuration information may also include information about at least the following: a time window during which the communication device is suitable for collecting energy from an external source (also called an ambient source) and / or frequency resources during which the communication device is suitable for collecting energy from an external source (also called an ambient source), and / or energy collection-related information during which the communication device is suitable for collecting energy from an external source (also called an ambient source).

[0014] Note that the configuration information may also include information about at least the following: a time window during which the communication device is awakened to detect a signal indicating whether a base station and / or other node has data to send to the communication device and / or has energy to be transmitted to the communication device, and / or a frequency resource at which the communication device is suitable for detecting a signal indicating whether a base station and / or other node has data to send to the communication device and / or whether the communication device can collect energy from an external source (also referred to as an ambient source). The signal may also include information about at least a device identifier and / or a device group identifier associated with the communication device and / or a communication device group.

[0015] Note that the configuration information may also include information about at least a device identifier and / or a device group identifier to wake up the communication device and / or the communication device group to be suitable for collecting energy from an external source (also called an ambient source), and / or sending a first safety report message, and / or receiving a safety report message from other nodes.

[0016] Note that if the communication device is outside the coverage of the base station device, it can indirectly receive configuration information from the base station device; and such configuration information can be relayed by one and / or multiple other devices (nodes) in the network on all paths starting from the base station device.

[0017] Note that the communication device as a node can be a tag, which can be read to obtain the characteristics of the tag. The characteristics may include the identity of the tag. By knowing which base station the identity of the tag is delivered to, it is possible to infer the (rough) location of the tag. The characteristics may also include a device type, which refers to the type of device it belongs to or to the type of device / product to which it is attached. In the case where the communication device as a node is a tag, the security report message of the node or another node may include (or itself may be) a security tag report message.

[0018] According to a second aspect, there is provided a method of determining characteristics (e.g., location, identity, device type, etc.) of a communication device as a node in a wireless network, wherein the method may include:

[0019] generating a first safety report message;

[0020] For example, if the communication device is within the coverage of the base station device, then receiving configuration information from the base station device indirectly or directly; and

[0021] Sending the first safety report message;

[0022] The configuration information includes at least information about at least the following items: a time window during which the communication device is suitable for sending a first safety report message to a base station device and / or to another node and receiving a safety report message from other nodes, and / or a frequency resource during which the communication device is suitable for sending a first safety report message to a base station device and / or to another node and receiving a safety report message from other nodes.

[0023] Note that the configuration information may also include information about at least the following: a time window during which the communication device is suitable for collecting energy from an external source (also called an ambient source) and / or frequency resources during which the communication device is suitable for collecting energy from an external source (also called an ambient source), and / or energy collection-related information during which the communication device is suitable for collecting energy from an external source (also called an ambient source).

[0024] Note that the configuration information may also include information about at least the following: a time window during which the communication device is awakened to detect a signal indicating whether a base station and / or other node has data to send to the communication device and / or has energy to be transmitted to the communication device, and / or a frequency resource at which the communication device is suitable for detecting a signal indicating whether a base station and / or other node has data to send to the communication device and / or whether the communication device can collect energy from an external source (also referred to as an ambient source). The signal may also include information about at least a device identifier and / or a device group identifier associated with the communication device and / or a communication device group.

[0025] Note that the configuration information may also include information about at least a device identifier and / or a device group identifier to wake up the communication device and / or the communication device group to collect energy from an external source (also called an ambient source), and / or send a first safety report message, and / or receive a safety report message from other nodes.

[0026] Note that the configuration information may also include information at least about the number of repetitions of repeated transmissions of the physical packet of the safety report message from the communication device.

[0027] Note that the configuration information may also include information about at least data replication from the communication device.

[0028] According to a third aspect, there is provided a system which may comprise in a wireless network at least a plurality of communication devices of the first aspect, a plurality of base station devices and a core network location service adapted to determine a location estimate of a target communication device among the plurality of communication devices.

[0029] Finally, according to a fourth aspect, a computer program product is provided which may comprise code means for producing the steps of the method according to the second aspect when run on a computer device.

[0030] According to a first option which may be combined with any one of the above first to fourth aspects, transmission of the first safety report message may be performed at a time window and / or performed using a frequency resource depending on an identifier.

[0031] According to the second option which may be combined with the first option and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0032] receiving a security report message from one or more other nodes as a second security report message;

[0033] In response to receiving at least some of the second safety report messages, generating respective observation reports associated with receiving the at least some of the second safety report messages; and

[0034] The observation report is selectively embedded in the first safety report message.

[0035] According to a third option which may be combined with the first option or the second option and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0036] receiving a timing reference from a synchronization signal when the communication device is within coverage of a synchronization source; and

[0037] When the communication device is not in coverage of a synchronization source, at least one second safety report message is received from at least one nearby node of the one or more other nodes to infer a timing reference.

[0038] According to a fourth option which may be combined with any one of the first to third options and / or the above first to fourth aspects, the communication device may be adapted to:

[0039] The received configuration information is embedded in the first security report message as a configuration data field.

[0040] According to the fifth option which can be combined with the first to fourth options and / or any of the above first to fourth aspects, the configuration data field may include at least a predefined target quantity type to control and / or influence and / or constrain the size of the first safety report message.

[0041] According to a sixth option which may be combined with any one of the first to fifth options and / or the above first to fourth aspects, the communication device may be adapted to:

[0042] The transmission power thereof is controlled by a predefined transmission control policy determined based on the received configuration information for sending the first safety report message.

[0043] According to the seventh option which may be combined with any one of the first to sixth options and / or any one of the above first to fourth aspects, the first security report message may include at least a security portion data field which is an output of a cryptographic function on a plurality of data items.

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

[0045] According to a ninth option which may be combined with any one of the first to eighth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0046] embedding a payload in the first security report message; and

[0047] The first security report message is sent including an embedded payload, the payload being an output of a locally computed cryptographic function.

[0048] According to a tenth option which may be combined with any one of the first to ninth options and / or any one of the first to fourth aspects above, selectively embedding the observation report in the first safety report message may include:

[0049] selecting among the observation reports an observation report that has previously been sent a number of times less than a predefined threshold; and / or

[0050] Select the newer observation report among the observation reports; and / or

[0051] selecting, among the observation reports, an observation report having no indication that the selected observation report has been sent by a node within the coverage area of ​​the base station device;

[0052] and / or

[0053] Select an observation that has been flagged or identified as high priority.

[0054] as well as

[0055] The selected observation report is included in a first safety report message to be sent.

[0056] According to an alternative of the tenth option which may be combined with any one of the first to ninth options and / or any one of the first to fourth aspects above, selectively embedding the observation report in the first safety report message may include:

[0057] selecting an observation report among those observation reports that have been previously sent a number of times equal to or greater than a predefined threshold; and / or

[0058] selecting an older observation report among said observation reports; and / or

[0059] as well as

[0060] During the time window, the selected observation reports are prevented from being embedded in the first safety report message to be sent as part of the first safety report message, while the unselected observation reports are sent in the observation report.

[0061] According to an eleventh option which may be combined with any one of the first to tenth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0062] If no time slots within the time window and on the transmission frequency channel of the frequency resource are free, or if the percentage of occupied time slots within the time window is above a predefined threshold, the time window itself is automatically extended.

[0063] According to a twelfth option which may be combined with any one of the first to eleventh options and / or the above first to fourth aspects, the communication device may be adapted to:

[0064] If the communication device is located on a cell boundary, receiving another configuration information from another base station device, the cell boundary separating a cell in the coverage of the base station device from another cell in the coverage of the another base station device, the another configuration information comprising at least information about another time window during which the communication device is suitable for sending and receiving and other frequency resources suitable for the communication device to use for sending and receiving; and

[0065] Conditionally sending during both the time window and the another time window.

[0066] According to the thirteenth option which can be combined with any option from the first option to the twelfth option and / or any aspect from the first aspect to the fourth aspect above, the core network location service can be suitable for receiving a security report message sent as a unicast message from a communication device among multiple communication devices, or receiving changes in the security report message directly from a base station device among multiple base station devices when the base station device receives the security report message from a communication device within the coverage of the base station device, and the changes in the security report message correspond to the security report message or at least one security element thereof embedded in an observation report generated by the base station device.

[0067] According to a fourteenth option which may be combined with any one of the first to thirteenth options and / or any one of the first to fourth aspects above, the core network location service may be adapted to perform cryptographic function calculations by:

[0068] using the security portion data field as input for each received security report message; and / or

[0069] using some input and comparing the output of said cryptographic function with said secure portion data field,

[0070] And in response, identifying the true identity of the target communication device.

[0071] According to a fifteenth option which may be combined with any one of the first to fourteenth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0072] receiving configuration information from a base station device and / or other device using RF backscatter communications; and / or

[0073] The first safety report message is sent using the RF backscatter communication.

[0074] According to the sixteenth option which can be combined with any one of the first to fifteenth options and / or any one of the first to fourth aspects above, the core network location service can be suitable for exposing the collected location information of the communication device to external authenticated and authorized users and / or services.

[0075] According to a seventeenth option which may be combined with any one of the first to sixteenth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0076] If the communication device is located on a cell boundary, receiving another configuration information from another base station device, the cell boundary separating a cell in the coverage of the base station device from another cell in the coverage of the another base station device, the another configuration information comprising at least information about another time window during which the communication device is suitable for sending and receiving and about other frequency resources suitable for sending and receiving by the communication device; and

[0077] Conditionally receiving during both the time window and the further time window.

[0078] According to an eighteenth option which may be combined with any one of the first to seventeenth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0079] If the communication device is located on a cell boundary, receiving another configuration information from another base station device, the cell boundary separating a cell in the coverage of the base station device from another cell in the coverage of the another base station device, the another configuration information comprising at least information about another time window during which the communication device is suitable for sending and receiving and about other frequency resources suitable for sending and receiving by the communication device; and

[0080] conditionally transmitting during both the time window and the another time window using RF backscatter communications;

[0081] as well as

[0082] RF backscatter communications are conditionally received during both the time window and the further time window.

[0083] According to a nineteenth option which may be combined with any one of the first to eighteenth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0084] Energy is collected according to configuration information received from a base station device and / or other devices.

[0085] According to the twentieth option which may be combined with any one of the first to nineteenth options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0086] If the communication device is located on a cell boundary, receiving another configuration information from another base station device, the cell boundary separating a cell in the coverage of the base station device from another cell in the coverage of the other base station device, the another configuration information further comprising at least information about: another time window during which the communication device is suitable for collecting energy from an external source (also called an environmental source) and / or other frequency resources during which the communication device is suitable for collecting energy from an external source (also called an environmental source) and / or another energy collection related information about the communication device being suitable for collecting energy from an external source (also called an environmental source); and

[0087] Energy is conditionally harvested during the time window and the further time window.

[0088] According to the 21st option which may be combined with any one of the 1st to 20th options and / or any one of the above 1st to 4th aspects, the communication device may be adapted to:

[0089] receiving configuration information from a base station device and / or other device, and the configuration information may further include information about at least the following: a time window during which the communication device is suitable for collecting energy from an external source (also referred to as an environmental source) and / or a frequency resource during which the communication device is suitable for collecting energy from an external source (also referred to as an environmental source) and / or energy collection related information during which the communication device is suitable for collecting energy from an external source (also referred to as an environmental source); and

[0090] Energy is conditionally harvested during the time window.

[0091] According to the 22nd option which may be combined with any one of the 1st to 23rd options and / or any one of the above 1st to 4th aspects, the communication device may be adapted to:

[0092] Configuration information is received from a base station device and / or other device, and the configuration information may also include information about the following: a time window during which the communication device is awakened to detect a signal indicating whether the base station and / or other node has data to send to the communication device and / or has energy to be transmitted to the communication device, and / or a frequency resource that the communication device is suitable for detecting a signal indicating whether the base station and / or other node has data to send to the communication device and / or whether the communication device can collect energy from an external source (also referred to as an ambient source). The signal may also include information about at least a device identifier and / or a device group identifier associated with the communication device and / or a communication device group; and

[0093] Conditionally wake up to detect the signal during the time window.

[0094] According to a twenty-third option which may be combined with any one of the first to twenty-second options and / or any one of the above first to fourth aspects, the communication device may be adapted to:

[0095] receiving configuration information from a base station device and / or other devices, wherein the configuration information may also include at least information of a device identifier and / or a device group identifier, so as to wake up the communication device and / or the communication device group to collect energy from the external source (also referred to as an environmental source), and / or send the first safety report message, and / or receive a safety report message from the other node;

[0096] Conditionally wake up to harvest energy from an external source (also referred to as an ambient source), and / or send a first safety report message, and / or receive a safety report message from other nodes.

[0097] According to the twenty-fourth option which may be combined with any one of the first to twenty-third options and / or any one of the first to fourth aspects above, the base station and / or other access equipment may be adapted to:

[0098] sending one or more impinging signals to a communication device at different times, frequencies, and / or spatial locations to cause the communication device to reflect the backscattered RF signals to send a safety report message; and

[0099] One or more reflected backscattered RF signals reflected from the communication device are received, and multiple copies of the received multiple reflected backscattered RF signals may be conditionally combined (partially or completely) to jointly decode the transmitted safety report message.

[0100] According to the twenty-fifth option which may be combined with any one of the first to twenty-fourth options and / or any one of the first to fourth aspects above, the base station and / or other access equipment may be adapted to:

[0101] One or more reflected backscattered RF signals reflected from a communication device are received at one or more locations in addition to or in lieu of a transmission location, and multiple copies of the reception of the reflected backscattered RF signals received at different locations can be conditionally combined (partially or completely) to jointly decode a transmitted safety report message.

[0102] Note that the above-mentioned apparatus may be implemented based on discrete hardware circuits having discrete hardware components, an integrated chip or a chip module arrangement, or based on a signal processing device or chip controlled by a software routine or program stored in a memory, written on a computer-readable medium or downloaded from a network such as the Internet.

[0103] It shall be understood that the communication device according to claim 1, the method according to claim 14, the system according to claim 15 and the corresponding computer program product may have similar and / or identical preferred embodiments, in particular as defined in the dependent claims.

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

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

[0106] In the following figures:

[0107] Figure 1 schematically illustrates an example OoC scenario in a location system in a 2D plane with distribution of tags and anchor nodes within and outside the coverage of a cell;

[0108] Figure 2Schematically illustrates an example scenario in a location system with one cell according to an embodiment of the present invention;

[0109] Figure 3 Schematically illustrates a basic cellular location and communication system architecture according to an embodiment of the present invention;

[0110] Figure 4 Schematically shows an embodiment of the present invention Figure 3 Example extensions of the basic cellular location and communication system architecture;

[0111] Figure 5 Schematically shows a method based on an embodiment of the present invention Figure 4 An example deployment of a location system of a system architecture, wherein tags, anchor nodes, and SL UEs within and outside of coverage are distributed through a cell in a 2D plane;

[0112] Figure 6 Schematically illustrating an example private configuration by a gNB of a Tx time window for a tag according to an embodiment of the present invention;

[0113] Figure 7 Schematically illustrates an example OoC scenario in a location system, where tags and anchor nodes in and out of coverage are distributed over two cells in a 2D plane;

[0114] Figure 8 A signaling and processing diagram schematically illustrates a communication process between an access device and a tag according to an embodiment of the present invention;

[0115] Fig. 9 Schematically illustrates a signaling and processing diagram between an access device and a tag involving an authentication process between a network and a tag according to an embodiment of the present invention;

[0116] Fig.10 Schematically illustrates a signaling and processing diagram between an access device and a tag according to an embodiment of the present invention, wherein tags within coverage rebroadcast requests from the access device;

[0117] Fig.11 Schematically illustrates an example of allocating timing and frequency resources for a reply from a tag based on an identity value according to an embodiment of the present invention;

[0118] Fig.12 An example of waking up a tag by using a wake-up signal sent in different time resources and frequency resources according to an embodiment of the present invention is schematically shown; and

[0119] Fig.13An example of a wake-up signal packet format designed as a wake-up tag according to an embodiment of the present invention is schematically shown.

[0120] Fig.14 is a flow chart depicting a process in an energy harvesting embodiment. DETAILED DESCRIPTION

[0121] Tags can be used to implement multiple use cases, such as asset tracking or identification of assets. The tag can be attached to an asset, and the identity provided by the tag and received by the reader can allow the characteristics of the asset to be determined, including, for example, at least one of the identity of the asset, the type of asset, the location of the asset, and a sensed value (if the tag includes, for example, a small sensor suitable for sensing the value).

[0122] The following embodiments of the present invention are described in particular based on location (also interchangeably designated as "localization" or "positioning") services for cellular networks, where, for example, 4G network elements can be incorporated into the proposed 5G solution. In addition, at least some of the following embodiments are described based on 5G New Radio (5G NR) radio access technology. However, the present invention can also be used in conjunction with other wireless technologies that can support tags (e.g., IEEE802.11 / Wi-Fi or IEEE 802.15.4 / Ultra-Wideband Communication (UWB)).

[0123] Throughout this disclosure, the term "wireless network" is intended to mean the entire network system (e.g., 4G or 5G system) including at least communication equipment (e.g., UE), a radio access network (RAN), and optionally a core network (CN). In addition, the abbreviations "eNB" (4G terminology) and "gNB" (5G terminology) are intended to mean access equipment, such as a cellular base station or WiFi access point or UWB PAN coordinator. The eNB / gNB is part of the RAN, which can provide an interface to any function in the CN. The RAN is part of a wireless communication network. It implements the radio access technology (RAT). Conceptually, it provides a wireless network infrastructure residing between communication devices such as mobile phones, computers, or any remotely controlled machines, and can provide connections to their CN. The CN is the core part of the communication network, which provides many services to customers interconnected via the RAN. More specifically, it guides communication flows through the communication network and possible other networks.

[0124] Out-of-coverage and limited coverage communications

[0125] In the 3GPP specifications TS23.303, 23.304, 24.334 and 24.554 for 4G and 5G networks respectively, the so-called Proximity Services (ProSe) functionality is defined to enable the connection of cellular communication devices (e.g., UEs) that are temporarily out of the coverage of access devices (e.g., eNBs, gNBs). This specific functionality is called ProSe UE to Network (U2N) Relay or Relay UE. 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 services in both directions between another OoC UE and an access device (e.g., eNB, gNB). 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 defined by 3GPP for sidelink communication of ProSe. In addition, the abbreviation "UL" is used for an uplink direction from a communication device (e.g., UE) to an access device (e.g., eNB, gNB), the abbreviation "DL" is used for a downlink direction from an access device (e.g., eNB, gNB) to a communication device (e.g., UE), and the abbreviation "SL" is used for sidelink communication between two or more communication devices (e.g., UE).

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

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

[0128] ProSe can also be used for direct communication between two UEs. Additional radio-level details on ProSe, V2X, and sidelink communications can be found in, for example, 3GPP specifications TR 37.985, TS 38.300, and TR 38.836. However, its use can be problematic for low-power tags due to the high resource requirements of acting as a L2 or L3 U2N relay and a L2 or L3 U2N remote UE.

[0129] In addition to the scenario where the tag is Out of Coverage (OoC) of the wireless network infrastructure, the tag may also be in Limited Coverage (LiC), i.e., a scenario where the tag can receive transmissions from the gNB but cannot transmit back due to its limited transmit (Tx) power, or conversely, a scenario where the tag cannot receive transmissions from the gNB, but can transmit to it (although it may not be certain that the gNB can hear it (e.g. because the tag uses a lower cost, simpler RF receiver than the gNB)). Nodes that are in coverage of the wireless network infrastructure may typically act as (primary) anchor nodes.

[0130] OoC / LiC may occur due to various reasons, such as RF signal obstruction due to objects or buildings, limited Tx power of the tag, limited Tx energy of the tag (e.g., in cases where the hardware can generate enough Tx peak power, but not enough energy to complete the transmission at the required output power. This may occur, for example, for energy harvesting tags or battery-powered tags with lifetime requirements), and / or entering an area where the network infrastructure is sparse, and / or there is no mobile anchor point temporarily but statistically dependent on the presence of mobile anchor points. Since the nodes in the network infrastructure (such as gNB) are mostly used as anchor nodes, this means that for these OoC / LiC tags, the location cannot be estimated with the required accuracy. In addition, the communication between these OoC / LiC tags and the wireless network infrastructure may be challenging, so the tag may not be able to receive relevant configuration information (e.g., transmission time scheduling, reception time scheduling, Tx parameters, frequency / resource information, payload / report format, etc.) from the gNB regarding the execution and configuration of the corresponding positioning process.

[0131] Figure 1 An exemplary OoC situation in a positioning system with one cell is schematically shown, where in-coverage tags 101, 102, 103 and out-of-coverage tags 111, 112, 113, all represented by small circles, will be located in a 2D plane within an X / Y coordinate system. As shown, tags 101, 102, 103, represented by small empty circles, can transmit RF signals, which can be received at anchor nodes 121, 122, 123, 124, represented by large circles. Tags 111, 112, 113 represented by small filled circles are OoC and cannot send to or receive from anchor nodes 121, 122, 123, 124 represented by large circles, but can send to and also receive from nearby tags 101, 102, 103 represented by small empty circles, as represented by the double-headed arrows.

[0132] Therefore, tag-to-tag transmission and measurement may be required, rather than only tag-to-infrastructure transmission. However, in the case of low-power tags, due to their very low energy consumption, the need to harvest energy and / or long (battery) life requirements, tag-to-tag transmission and / or tag-to-measurement cannot be performed continuously and the tag's radio reception (Rx) and transmission (Tx) cannot be 100% of the time.

[0133] RF backscatter communications

[0134] Low power tags may have limited energy storage, and / or may not have any battery storage at all, and may need to use the concept of RF backscatter communication, also called ambient backscatter (sometimes also in combination with energy harvester devices). In backscatter communication, information may be modulated on top of an incoming incident signal (e.g. an RF lighting signal) (e.g. from a base station or other UE), thereby sending / reflecting the modulated signal so that a nearby base station or other UE can receive the modulated signal. This backscatter communication method is useful for very low power devices, typically but not necessarily operating without any internal energy source during the use of backscatter communication. There may be a number of cases (= device categories):

[0135] 1. The device has an internal energy source that can be used for regular 3GPP communications, but is able to switch to backscatter communications as needed at certain times to limit energy consumption from its internal energy source to very low levels, or not use any energy from its internal source at all by using some form of energy harvesting (such as RF energy harvesting or vibration energy harvesting).

[0136] 2. The device has no internal energy source, and the only available energy source is energy harvesting through RF waves, vibration energy, etc.

[0137] 3. The device has no internal energy source but has other external energy sources that can be intermittent, such as solar energy, wind energy, thermal energy and / or salinity gradient, in addition to energy harvesting from RF waves or vibration energy. During the time when the mentioned external energy source does not provide enough energy, it can fall back to energy harvesting, for example from RF waves or vibration energy.

[0138] The cell site and / or UE can directly provide a strong RF signal to the low power tag, which can transmit data to the low power tag and can provide energy for the RF collector of the low power tag. In 3GPP, for ordinary UEs (such as mobile phones expected to have internal energy sources), support for resource scheduling (in time, frequency and / or spatial domains) for control signaling and data services (i.e., RRC signaling, downlink control information (DCI), uplink control information (UCI), sidelink control information (SCI), MAC control elements (CE), etc.) in downlink, uplink and sidelink has been specified. However, for low power tags with very limited and possibly no internal energy sources, it is not clear whether the same resource scheduling method can be reused for intermittent communication of low power tags. In addition, 3GPP does not yet support the transmission of energy transmission scheduling and profiles, and / or backscatter communication scheduling and profiles from cell sites and / or UEs to low power tags. Because low power tags are lightweight and low complexity devices in wireless networks, it is very important to design effective methods to support these aspects in the present invention.

[0139] Positioning systems in cellular networks

[0140] Embodiments of the present invention are particularly concerned with determining the location of wireless devices in a cellular network while using very little power on the wireless device and very simple radios. These properties allow small, low-cost devices to be used in cellular systems (battery powered or battery-free). Battery-free devices can collect power from the environment (e.g., from sunlight, motion, vibration, or RF signals). In this disclosure, these devices are referred to as "tags" and can be considered to be a specific class of user equipment devices (UE) that can implement a subset of the 3GPP specifications. Note that the wireless device can be mobile or stationary, or intermittently mobile and stationary.

[0141] In a positioning system, multiple types of devices may participate in providing positioning functionality. These types of devices may include tags, mobile UEs that are more powerful than tags (e.g., smartphones or V2X-connected vehicles), or infrastructure devices (e.g., gNBs, mobile gNBs, or V2X roadside units). In this disclosure, the term "node" may be used for such participating devices, such that a node may be a UE and a tag may also be a node.

[0142] Some nodes may be referred to simply as “anchor nodes” or “anchor points.” These are devices participating in a positioning system that have a 2D or 3D position that is already known to the system with a certain degree of accuracy, for example because these participating devices never move (e.g., fixed infrastructure nodes), or because they use cellular positioning technology that enables a cellular network to determine the location of the UE (e.g., TDOA), or because these participating devices can use a global navigation satellite system (GNSS) (e.g., Global Positioning System (GPS)) to determine their position with high accuracy.

[0143] Some location solutions let nodes determine the node's location using only measurements of anchor nodes. Other location solutions let nodes also interact with other non-anchor nodes to determine their location. The latter is sometimes called "cooperative positioning" or "peer positioning".

[0144] For the purposes of this disclosure, the following three main categories of wireless location / positioning solutions may be considered:

[0145] 1. "Range-based" category: Nodes measure mutual ranges and / or distances to peer nodes. 2D or 3D positions can then be calculated from multiple distance measurements and some known anchor positions:

[0146] a. These measurements involve techniques like RF and / or acoustic time-of-flight measurements to measure distance;

[0147] b. RF time-of-flight measurements typically require very accurate (and expensive) clocks and high-bandwidth RF signals on participating nodes;

[0148] 2. “No range” category: the node does not measure range, but only measures to peer nodes (e.g. using identities of peers discovered on sidelink) or infrastructure devices (e.g. identified using cell ID, e-CID) or known areas (e.g. service / tracking / registration / coverage areas identified using Tracking Area Identifier (TAI), optionally using some signal strength indication:

[0149] a. Based on multiple presence measurements (optionally also from signal strength measurements) and some known anchor point locations, a 2D or 3D position can be estimated. The estimate can include a single position result (i.e., the "most likely position"), or it can include a probabilistic model (i.e., multiple location regions labeled with the likelihood of a node's presence);

[0150] b. Typically, the range-free class usually means lower energy consumption and lower cost for the node, but also means lower accuracy, relative to the "range-based" class;

[0151] 3. Other categories, including: Angle of Arrival / Departure (AoA / AoD), Hybrid, Simultaneous Localization and Mapping (SLAM).

[0152] Embodiments of the present disclosure may target a "no range" category to achieve the lowest energy usage / complexity for the tag while attempting to compensate for the lower accuracy of using presence and optional signal strength measurements compared to the "range-based" category, but "does not" exclude range-based or other positioning / location solutions (e.g., GNSS) from being supported by the tag.

[0153] Location solutions can also be broadly divided into two categories: real-time and non-real-time. In a real-time location system, location measurements / estimates can be made to applications in real-time, within a certain guaranteed maximum time delay. For some applications, this may be a few milliseconds, while for other types of applications, this may be a few seconds or even minutes. For non-real-time location systems, there is no such strict requirement; even if some unpredictable delays are implied in some cases (for example, the data required to fully estimate the location of the tag may be hours or even days after the tag is located at the location), the focus is more on collecting reliable and trustworthy records of the past locations of devices / tags / entities. In order to achieve this reliable record, it is of key importance to reliably associate measurements with timestamps. The location service of a non-real-time system should be able to establish the integrity / trustworthiness of the location estimate of the tag over time by correlating multiple measurements of the tag's signal over a period of time to form a reasonable hypothesis of the movement of the tag during the period (if any). This can include executing processes such as processing (delayed) tag sightings associated with tags photographed at some time in the past, and retroactively adjusting the location estimate of the tag at a past time, for example, adjusting the trajectory hypothesis of a mobile tag over time based on new evidence. These processes for updating past information are generally not suitable for real-time systems.

[0154] Both types of systems are targets for the present invention, although for real-time applications, demanding applications (e.g., location determination latency between milliseconds and 1 second for >99.9% of measurements), other dedicated tracking solutions are generally more appropriate. Some embodiments provide specific elements that are best suited for non-real-time positioning systems, such as elements for configuring long tag report reporting periods (e.g., hours or days), or elements for out-of-coverage (OoC) operation of tags, or including tag sightings in tag reports sent during the next time window (which can be minutes or hours later than the time of tag sighting).

[0155] These wireless positioning solutions utilize RF messages sent by nodes that can be received and recorded by nearby nodes. In the present disclosure, such RF messages are referred to as "tag reports" or interchangeably as "tag report messages," and the event of receiving a tag report and associated metadata for the event is specifically referred to as "tag sighting" or in a more general manner as an "observation report."

[0156] Time Synchronization

[0157] To minimize energy consumption, transmissions may need to be intermittent, e.g. every few seconds in one use case, and every N minutes, hours, or even days in other use cases. In scenarios where tags will only interact directly with infrastructure and / or more powerful anchor nodes (such as V2X UEs installed in vehicles), then there is no need to synchronize the operation of multiple tags in a timely manner. However, in order to achieve good quality position estimates in cases of low coverage of anchor nodes (including the above case with OoC / LiC tags), tag-to-tag measurements are also needed.

[0158] Therefore, if tags may have long or even very long sleep periods during which their radio transceivers are turned off, it is necessary to perform peer-to-peer (i.e. tag-to-tag) data transmission and reception (see Figure 1 If a tag is located on a network (with double-sided arrows connecting small circles in the figure) for positioning, then the operations of all involved tags need to be synchronized in time so that within a short time window, all tags are listening (Rx) to tag transmissions and all tags have the opportunity to send (Tx) their own data; the purpose of all this is to enable the infrastructure or network to determine the tag location based on observed measurements of tag data transmissions. It would be ideal if the infrastructure nodes and / or all anchor nodes could ensure that the latest configuration information with a time schedule is distributed to all tags, for example by broadcasting. However, this may not be applicable to OoC / LiC tags. .

[0159] Furthermore, if many tags become active during the same narrow time window, mutual interference may occur. This is why the time window needs to be as short as possible to save energy in the tags while being long enough to enable all tags to transmit without interfering too much. This assumes that all tags in an area or a group of tags in an area that is a subset of the total set of tags are using the same RF band or channel for transmissions with the risk of potential interference. In cellular systems, scheduling is usually used to minimize interference. However, in the case of OoC / LiC tags where time synchronization with the gNB of the cellular network cannot be easily achieved, this scheduling becomes challenging. Indeed, keeping an accurate clock is energy consuming and keeping a less accurate clock on the tag saves energy during the long sleep time of the tag. Therefore, even if such OoC / LiC tags transmit according to a pre-configured schedule, their timing and frequency resources may overlap with those of peer tags, causing interference, or they may completely miss the allocated time window if their corresponding clocks are too inaccurate and / or the time window is short.

[0160] Contact tracing systems and privacy protection

[0161] It is known from contact tracing systems based on wireless signals (e.g. Bluetooth) that the proximity of a specific class of people (e.g. an infected person) carrying a wireless device can be detected after the fact without revealing any identifying information about the person or their wireless device. This can be achieved by sending a unique random code to the receiving device, which records the received code for later comparison in a network database. This also does not reveal any location information of the people and / or devices involved.

[0162] It is worth noting that preserving privacy is also important for positioning systems like contact tracing systems: no tag, even if nearby, should be able to learn the identity or location of another tag unless there is an explicit intent to disclose the information. In most use cases, the authority to collect data that estimates location lies with entities residing in the network infrastructure, not with the tags. As a result, other tags, such as nearby tags, generally cannot learn any location or identity information about a given tag. But in many use cases, it is useful and / or acceptable for a tag to learn its own location; in such cases, tags can disclose information only when needed and to parties authorized to process the information.

[0163] In general, any identity information and / or location information or fragments thereof associated with a tag is preferably not disclosed to other tags and / or anchor nodes. For example, in a transmitted message, an indication of the Tx power used by the transmitting tag is preferably not readable to the receiving entity or node. In addition, any reusable identifier (even a temporary identifier) ​​should preferably be hidden so that location tracking attacks on the tag are difficult to perform.

[0164] One known solution for privacy and confidentiality is to encrypt the information reported by each tag. The receiving entity (e.g., anchor and / or tag) saves this information in encrypted form and reports the information data to an authorized location service in the network, which is the only authorized participant that can decrypt the information based on key material associated with the identity of each reporting entity. Another known solution for contact tracing systems is to send a random code that can later be linked to a specific entity or node that was near another entity at a specific time using a database of secure locations. However, these known solutions raise the question of how the location service knows which decryption key to use if there may be millions of different tags reporting data, and knows that the identity of the reporting tag should not be included for the privacy reasons mentioned above. It is also important to have a privacy and security solution that fits the limited resources of small tags.

[0165] Location Information and Replay Attack Confidence

[0166] Some existing approaches such as iBeacon have the problem that tag reports can be recorded and replayed, thereby spoofing the presence of a specific iBeacon, while the authenticity of the tag reports cannot be verified.

[0167] However, even when the location information and / or identity information in the tag reports are encrypted and protected (tamper-proof), a record and replay type attack may still be possible by a malicious entity that is able to obtain previously recorded transmissions of a tag that were completed at one location or multiple locations. The entity may claim to have received a tag report by a tag that was never actually sent to it, but which was sent at another time and / or location where the malicious entity may not even exist. The malicious entity may act as an anchor node in the positioning system. If a "good" tag report and a "malicious" tag report are thus reported to the infrastructure, it may be difficult for the location service in the infrastructure to determine who has the correct report or both are correct or both are wrong.

[0168] Optimal control of transmit (Tx) power

[0169] For tags, reducing their average Tx power for transmissions and also adopting a radio design with low peak Tx power is beneficial to low energy consumption and long (battery) life of the tag. However, due to the reduced radio transmission range, low Tx power presents the disadvantage of reducing the potential number of tag measurements that can be obtained by nearby tags, anchor nodes and / or infrastructure equipment. In a scenario where no nearby receivers can hear the tag's transmission, the transmission will then become useless and wasted. In another scenario where the tag can transmit at maximum (100%) Tx power, this may result in the maximum number of tag observations (i.e., successful reception of data transmissions to the tag) in other devices, but given that the same effect may have been achieved at, for example, 50% Tx power, this may also result in potential waste of energy for the tag.

[0170] One solution may be to automatically adjust the Tx power used by each tag to the optimal state. However, in the case of real-time control or execution of location services on the core network (CN), such Tx power adjustment of each tag may cause a large amount of overhead data traffic.

[0171] Efficient and scalable operations

[0172] For tags, it is fundamental to have energy-efficient operation. This means that requests to read tags should be completed in an efficient manner. Efficiency can refer to, for example, energy efficiency, i.e., having a low energy cost, or time efficiency, i.e., fast. Scalability can refer to the number of tags that can be read simultaneously.

[0173] 5G systems demonstrate efficient and scalable operations for how devices access the network or how many devices can access the network simultaneously. But even such efficient processes may be too demanding for labels.

[0174] Positioning system based on RF signal strength and presence measurement

[0175] Figure 2An example situation in a location system with one cell according to an example embodiment of the present invention is schematically shown, where within the coverage area, tags 201, 202, 203 represented by small hollow circles (in tag-to-tag transmissions shown by dashed double-headed arrows) will be located in a 2D plane within an X / Y coordinate system. Due to the RF signals (see arrows) sent by tags 201, 202, 203 within the coverage area to anchor nodes 221, 222, 223, 224 (represented by large circles, which are part of the cellular network network infrastructure), and the corresponding RF signal measurements performed by anchor nodes 221, 222, 223, 224 and tags 201, 202, 203, a location determination can be performed. Typically, the RF signal strength of the signals received by anchor nodes 221, 222, 223, 224 and tags 201, 202, 203 can be used to help estimate the tag location: the weaker the signal strength, the farther the tag is on average. As is well known, in such a system, the more anchor nodes there are, the better the accuracy of the location estimate is generally. It is also known that if multiple RF signal strength measurements are taken over time and input into a time-based location estimation model for a single tag, the accuracy can be improved. Such a time-based estimation model may be based on Kalman filtering, multi-hypothesis Kalman filtering, particle filters, neural networks, hybrids, etc. Although not shown, it is known that a similar location system can be mapped by reversing the Tx and Rx directions or taking measurements in both the Tx and Rx directions (double-headed arrows).

[0176] As described above, the measurement and recording of RF signals as tag reports sent by a specific tag may correspond to tag targeting. An infrastructure device (e.g., an anchor node like a gNB), another type of anchor node, or a tag may be the source of a tag targeting. In existing systems, the receiver of a tag report can often infer the identity of the sending tag from the tag report data, however, this is a problem for many use cases involving cooperating devices from multiple owners.

[0177] It is worth noting that the "multiple measurements" strategy, whereby the tag continuously repeats transmissions and / or measurements over time with short sleep periods, has the known disadvantage that the energy consumption increases linearly with the number of transmissions and / or measurements. Therefore, this strategy may not be feasible for very low power tag localization systems, but may be suitable for devices (tags) (e.g. mobile robots or phones) that are periodically charged during specific sessions that are limited in time (thus not 24 / 7 for weeks, months, years, etc.).

[0178] iBeacon, Bluetooth beacons, and other beacon systems

[0179] There are various types of beacon-based location systems based on Bluetooth Low Energy (BLE), such as Apple's iBeacon (iBeacon). These location systems fall under the above category of positioning systems based on RF signal strength and presence measurements. In the case of iBeacon, tag reports can contain the tag's unique ID, and BLE-enabled smart devices in the area can receive these tag reports and then report the tag's unique ID to the location service along with an estimated location (as determined by the receiving device in some other way (e.g., known GPS / Wi-Fi hybrid positioning systems)).

[0180] It is also known that (BLE) beacons can be configured to send their location coordinates from a dedicated coordinate system (e.g., for a museum app) or from a universal coordinate system (e.g., GPS coordinates). Thus, a device can infer its own location by looking at one or more tag reports from beacons with specific coordinate information and an estimated distance to each beacon.

[0181] Definition of terms

[0182] For convenience, some terms used extensively throughout this disclosure have been collected in the following non-exhaustive list of definitions:

[0183] Node: Any device with the capability to participate in a location system to determine tag location and / or participate in a communication system and / or participate in RF transmission and / or reception that harvests energy from an external source. Thus, for example, core network location services or network servers on the Internet are not considered according to the current definition of a node.

[0184] Tag: A device (e.g., UE) with optional sensor capabilities, one of whose characteristics is to be determined. A tag may be mobile, stationary, or intermittently mobile and stationary. The characteristic may be location, sensor value, device type, device status, etc.

[0185] Infrastructure Node: A typically fixed node (e.g., gNB) that is part of the wireless network infrastructure.

[0186] Anchor node: A communication device (e.g., UE) or an infrastructure node (e.g., gNB) with a fixed or otherwise known location (e.g., accurately determined by GPS), which helps determine the tag location.

[0187] Tag Report: An RF message sent by a tag to help determine the tag's identity and / or location. Optionally, the message may contain sensor data and / or status information about the tag.

[0188] Tag targeting: Receiving a tag report (or tag report message) sent by a tag, and metadata associated with that reception event (e.g., the (local) time of reception, the received signal strength of the tag report message, the received signal quality or identity of the receiver, etc.). Whenever the term "observation report" is found in this disclosure, it will be used to specify the specific term "tag targeting" in a more general way.

[0189] SL-UE / Sidelink UE: A UE with sidelink transmit / receive capability that can receive tag reports and can send its tag targeting to the reporting destination entity (e.g., RAN's gNB or CN's location service). The SL-UE can also act as an anchor point. It can also act as a synchronization source to nearby tags by sending sidelink synchronization signals.

[0190] gNB: A wireless access device (e.g., a base station) of a cellular network. It is typically an example of an infrastructure node and / or an anchor node.

[0191] Location Service (e.g. Location Management Function (LMF)): A network function of the CN (although in certain embodiments the network function can also be outside the CN, this is usually the case) that receives information (e.g. tag sightings) and based on all the information and its internal location model can estimate the location of the tag. It provides the tag location to authorized applications or authorized devices as a service.

[0192] OoC: Out of coverage of a wireless network (e.g., out of range of a suitable gNB), and / or out of range of an anchor node (e.g., a gNB or UE) associated to a suitable wireless network. This definition may, for example, cover the following OoC situations for a device:

[0193] 1. Out of gNB coverage but still within the range of one or more anchor nodes;

[0194] 2. Out of gNB coverage and beyond the range of any anchor node;

[0195] 3. Out of gNB coverage and out of range of any other node.

[0196] LiC: Limited Coverage (LiC) of a wireless network, i.e., a scenario where a device can receive transmissions from an access device (e.g., gNB) but cannot transmit back due to its limited transmit (Tx) power, or conversely, where a device cannot receive transmissions from an access device but can transmit to it.

[0197] System Architecture

[0198] Figure 3A basic cellular location and communication system architecture 300 according to an example embodiment of the present invention is schematically shown. Only a single tag 301 rather than multiple tags is depicted herein for simplicity of representation. The anchor node 321 of the RAN 320 is a 5G-NR base station gNB 321 represented by a large circle. A single tag 301 in the gNB coverage is represented by a small empty circle and sends a periodic tag report message 330 that can be received by multiple nearby nodes (as shown by the multiple arrows from the tag). The 5G-NR base station (gNB 321) receives the tag report message 330 as a nearby node and reports its own tag targeting to the location service 341 of the CN 340. The CN 340 can be, for example, a 5G core network. The CN 340 may include multiple network functions, including but not limited to a location management function (LMF) or a gateway mobile location center (GMLC) configured to manage positioning / location services provided to UEs (e.g., tags) or to other entities. It should be noted that Figure 3 The location service 341 may be a separate service that only collects reports and then sends the data further to the LMF (or other location service) in another form, or it may be this LMF (or other location service). For a specific tag (e.g., a tag owned only by this user), there may be multiple authorized clients 351, 352 (including potential clients in the cloud 351 and potential clients on the UE 352) that are allowed to use the location information calculated by the location service 441. Note that the tag itself (i.e., the same tag for which the location is calculated or another tag that has a legitimate interest in the location information) may be one of the potential clients on the UE 352. In the case where the tag is in the coverage of those gNBs, the tag location is determined based on its proximity to one or more gNBs residing at known locations. Note that in this example embodiment, for simplicity, only a single gNB 321 is depicted instead of multiple gNBs. gNB321 sends a synchronization signal 331 (sync signal) and configuration data 332 to tag 301, tag 301 synchronizes to the synchronization signal 331 and selects a time window based on the configuration data during which it sends its tag report message 330 and receives tag report messages 330 from other tags 301.

[0199] In an example embodiment, the tag report message 330 may be sent to the gNB 321 using one or both of the following methods:

[0200] 1.5G NR Sidelink (SL) discovery or multicast / broadcast messages;

[0201] 2.5G NR Uplink (UL) Communications

[0202] Depends on configuration and conditions. In one example, if a tag sees multiple gNBs nearby, it can switch to a mode that reports only to those multiple gNBs via UL communications. In another example, if a tag sees one or more gNBs nearby, it can send a discovery message plus a tag report message to that gNB via UL communications, e.g., for additional reliability, confirmation, and / or security as proof of presence. In another example, if a tag does not see a gNB (or other access device) nearby, it can use only SL discovery or multicast / broadcast messages.

[0203] Note that the first method (1) is expected to be the most lightweight and best saves energy for the tag relative to the second method (2).

[0204] Notice, Figure 3 The example embodiment of the basic system architecture 300 shows how the embodiment can be integrated into the overall (5G) communication system. It reuses and also extends the existing communication and signaling formats of the 3GPP New Radio (NR) sidelink discovery message or sidelink multicast / broadcast message. For example, the new components required to extend the 5G NR standard and implement the embodiments of the present invention may include the following extensions in a non-exhaustive list:

[0205] - Standardized tag report data format within SL discovery or SL multicast / broadcast messages, so that all nodes (e.g., tags, UEs or gNBs) can understand and use the same format, whereby tag reports can include a standardized security data section;

[0206] - A standardized format for configuration data (as determined by the gNB / RAN and encoded within the Flagging Report message);

[0207] – Within the tag: standard time window calculation algorithm;

[0208] - In-Tag: Standard Tag Targeting Selection Method (used to selectively include Tag Targeting in sent Tag Reports);

[0209] - Between tags and location service / CN: interface for retrieving a tag's temporary identity (ie tag-temp-id) or its set of tag-temp-ids in case of multiple tags.

[0210] As in Figure 4 The system architecture 400 is schematically shown in FIG. Figure 3The system architecture 300 can be extended with a sidelink capable UE (SL-UE) 460 that is in the coverage area of ​​the gNB 421 and collaborates in performing location determination of the tag, and an additional tag 411 represented by a small full circle and is out of coverage (OoC) of the gNB 421. The SL-UE 460 also receives tag report messages 430-b, 435-b for any nearby in-range tags, so the SL-UE 470 acts as an additional tag report collection node. After receiving the tag report message 430-b, 435-b, it reports the corresponding tag targeting it created based on the tag report message 430, 435-b to the reporting destination entity (e.g., directly to the location service 441 (via the gNB 421, which transparently transmits the reported data to the location service 441) or directly to its serving gNB 421 via the Uu uplink (UL) connection 470, where the gNB can process the data or report it to the location service 441 in another form later. These tag targetings are generally only useful if the location information of the SL-UE 460 is known. The location information can be an approximate location estimated by one or more gNBs based on the SL-UE signal 470, or it can be a location determination process purposefully performed for the SL-UE 460 using one of the known methods in 3GPP (e.g., a method utilizing the LPP protocol). Therefore, the tag targeting sent by the SL-UE 460 can contain the SL-UE's own location estimate, or the tag targeting can be enhanced with the SL-UE location information later (e.g., at the gNB 421 or location service 441). In a similar manner, where a signal direction estimate based on, for example, a multi-element antenna is available at SL-UE 460, the tag sighting may contain information about the direction of the received corresponding tag report signal (sent by the tag).

[0211] like Figure 4As shown, the SL-UE 460 can provide a sidelink synchronization signal (SL synchronization signal) 433 to the OoC tag 411, which can help the OoC tag 411 (small filled circle) to transmit at the correct time and frequency without interfering with other data services. As can be seen, the same tag report message 430 sent by the tag 401 can be received by different collection nodes, which are represented by the tag report reception event arrows 430-a, 430-b, 430-c: the neighboring tag (i.e., OoC tag) 411 in this embodiment for the tag report message reception 430-c, the SL-UE 460 for the tag report message reception 430-b, and the gNB 421 at the RAN infrastructure 420 for the tag report message reception 430-a. In certain circumstances (e.g., depending on RF signal propagation conditions, such as, for example, interference), it may happen that the sent tag report message 430 is not received by all nodes as described above. For example, if tag 401 sends three different tag report messages, it may be that each message is received by only one of the nearby nodes (e.g., by the corresponding gNB 421, the SL-UE 460, and the neighboring tag 411).

[0212] Although not depicted herein for simplicity reasons, it should be noted that the SL-UE 460 may also be connected to multiple gNBs and there may be multiple SL-UEs in the coverage area that are also capable of providing synchronization signals.

[0213] Energy Harvesting

[0214] In one embodiment (which may be used independently), a SL-UE 460 receiving a tag report message 430 (which may have a high priority) may increase transmit power and / or direct the signal beam and / or increase signal bandwidth / density and / or operate at a higher frequency for one or more transmission signals and / or send another type of high energy signal (e.g., based on Qi or other wireless power standards) in the direction of the device from which the tag report message 430 or other message originated and / or in a transmission signal used for its communication with the device from which the tag report message 430 or other message originated. To do this, the SL-UE 460 may derive an angle based on the angle of arrival or location information determined in the tag report or other message, and use the derived angle to configure its wireless transceiver to generate a signal beam using the beamforming capabilities of the antenna array of the SL-UE 460. Based on the available location information, it may also derive the distance between the SL-UE 460 and the device from which the message originated, and use the distance to configure the signal / beam (e.g., signal strength or beam width). This allows the device from which the tag report message 430 or other message originates to collect additional energy in the event that the SL-UE 460 transfers energy to the device from which the tag report message 430 or other message originates. To this end, a tag report message or sidelink discovery / multicast / broadcast or other message (e.g., an RRC message) received by the SL-UE 460 or other node from another node or sent by the node to another node may include a flag or attribute indicating that the node is collecting energy (e.g., collecting RF energy to enable its communication). Messages received / sent by / from a node (e.g., a tag report message or sidelink discovery / multicast / broadcast or other message) may also include a flag or attribute to indicate the type of energy collection supported by the node from which the message originates (e.g., RF-based energy collection (which may also include information about frequency range, minimum / maximum bandwidth, signal strength, signal type and / or energy density), solar panels, Qi). Such flags or attributes may be added or removed or changed by a node forwarding such a tag report, or to create a tag targeting or other message based on such a tag report or other received message, for example depending on whether the forwarding node itself collects energy. Alternatively, each node that forwards such a tag report or creates a tag targeting or other message based on such a tag report or other received message can add its own attribute / flag to indicate whether it supports energy harvesting and / or generates an aggregate message containing information received from other nodes. Each node can add angles (e.g., by measuring the arrival angle) between itself and the node from which it received the message (e.g., a tag report) in a field / attribute of a message (e.g., an aggregate tag report / tag targeting message) that it sends to another node, and / or can add angles between itself and the node to which it sent the message.Each node may also add an indication of a remaining energy budget (e.g., battery charge), a maximum energy budget (e.g., the amount of energy its capacitors can hold), an energy budget (e.g., an amount in joules or similar units of measurement) to send or receive subsequent messages, a request for an amount of energy to be supplied (e.g., RF-based), an estimated time (e.g., under current conditions, or calculated based on its requested or desired energy level) to expect to have enough energy to receive or send subsequent messages (e.g., based on preconfigured information (e.g., the minimum or maximum amount of energy that can be supplied, and / or the amount of energy given a particular energy density of an RF signal in a particular frequency) or based on historical data) to be supplied by other nodes or base stations during a period of time (which may be preconfigured).

[0215] The SL-UE 460 and / or other intermediate nodes (e.g., tags, small cell devices) that forward tag reports or other messages (e.g., upstream nodes one hop closer to the gNB, or the gNB itself) may provide information about the ability to provide energy to another node (e.g., a tag) by including such capability information (which may also include information about frequency range, bandwidth, ability to determine angle of arrival, type of energy collection, etc.) as part of a ProSe discovery / multicast / broadcast message (e.g., a ProSe identifier or relay service code or similar identifier, which may be pre-configured at another node (e.g., through a ProSe policy) to indicate a capability (or set of capability information) for providing energy to an energy harvesting device) or as part of a SIB or other regular message transmitted therein. The other node may receive this information and use it to select a forwarding node or determine whether to include the above-mentioned information related to energy harvesting (e.g., its energy harvesting capability or remaining energy budget). Additionally or alternatively, the other node may use the ProSe identifier or relay service code or similar identifier in a message to the SL-UE 460 and / or other intermediate nodes to indicate that it supports harvesting energy and / or requests that energy be provided for energy harvesting.

[0216] The SL-UE 460 and / or other intermediate nodes that forward tag reports or other messages from the 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 the energy collection capability information (e.g., received from a downstream node that is one hop further from the gNB) and / or angle information (e.g., the angle between it and the first node) that it receives from the first node, for example, during a communication session between the first node (or another downstream node or upstream node) and the network, for example, in the case where a message is forwarded from a downstream node to the network, during a time when downlink messages can be received from the network, or during a wake-up period of the first node or the node itself, and then use this information to increase transmit power and / or steer signal beams and / or increase signal bandwidth / density and / or operate one or more transmission signals at a higher frequency and / or send another type of high-energy signal (e.g., based on Qi or other wireless power standards) in the direction of the first node to provide energy for the first node to receive downlink or uplink messages from the node or network, or to enable the first node to send subsequent messages.

[0217] In one example, when the gNB, SL-UE 460, or other intermediate node generates or receives a downlink message to be sent to a downstream node, the gNB, SL-UE 460, or other intermediate node first provides a certain amount of energy to the downstream node (e.g., by directing a high energy signal / beam) based on information received from the downstream node and / or based on angle / distance / position information from the downstream node before sending the message to the downstream node. In a specific example, the first portion of the signal / carrier may be purely for energy transfer, while the latter portion of the signal / carrier may be used for both energy transfer and data transfer.

[0218] In addition to the SL-UE 460 or other intermediate nodes that provide energy to downstream nodes, the SL-UE 460 or other intermediate nodes that have received the tag report message 430 (which may have a high priority level) may request the network (e.g., gNB 421) to increase transmit power and / or direct the signal beam and / or increase signal bandwidth / density and / or operate at a higher frequency for one or more transmission signals and / or in the direction of the device from which the tag report message 430 or other message originated and / or in a transmission signal for its communication with the device from which the tag report message 430 or other message originated and / or to send another type of high energy signal (e.g., based on Qi) in a transmission signal toward the SL-UE 460. To this end, the SL-UE 460 may add a flag or attribute in the tag report / tag targeting message it sends to the network (e.g., gNB 421) to instruct the tag and / or SL-UE 460 to collect energy, possibly with angle and / or positioning information and / or other energy collection related information (e.g., capabilities, remaining energy budget, etc.) related to the SL-UE 460 and the device from which the tag report message 430 or other message originated. Alternatively, it may send a separate message (e.g., an RRC message) indicating such a request and (a subset of) the above information. Based on such a request and the information provided or the network having other information about the SL-UE 460 and the tag report message 430 or other device from which the message originated (e.g., capability information of the SL-UE 460 or the device from which the message originated, which may have been received in an earlier message (e.g., an RRC UE capabilities message) and which may include information about the types of energy collection supported) and / or fields in subscription data (e.g., stored in the UDM / UDR, which indicates support for energy collection (and which may also include information about the types of energy collection supported), which may be retrieved by the AMF or gNB or other network function based on an identity received from the SL-UE 460 or the device from which the message originated and / or location data that may be available for the SL-UE 460 or the device from which the message originated)), the network (e.g., gNB 421) may adjust its transmission scheme. To this end, the gNB 421 may derive an angle based on the determined angle of arrival and / or other available position or angle information, and use the determined angle to configure its wireless transceiver to generate a signal beam in the direction of the SL-UE 460 or device from which the message originated using the beamforming capabilities of the antenna array of the gNB 421. Based on the available position information, it may also derive the distance between the gNB and the SL-UE 460 or device from which the message originated, and use the distance to configure the signal / beam (e.g., signal strength or beam width).In addition, the network (e.g., gNB 421) can identify (e.g., based on aggregated messages from forwarding nodes) that UE 460 and / or any other node that forwards tag report message 430 to the network may be devices that use energy harvesting as an energy source and also increase transmit power and / or direct beams and / or increase signal bandwidth / density and / or operate at a higher frequency for one or more transmission signals and / or send another type of high energy signal (e.g., based on Qi) in the direction of these devices and / or in the transmission signals used to communicate with these devices.

[0219] In another embodiment (which can be used independently), a communication device using energy harvesting (i.e., an energy harvesting device) (such as the above-mentioned device that sends / has previously sent a tag report message 430) can request another device (e.g., UE 460) and / or gNB 421 in its tag report message 430 or in a PC5 message (e.g., a discovery message) via a direct connection to the network (e.g., an RRC or MAC message sent to the gNB via Uu) or via an indirect connection to the network (e.g., an RRC message sent to the gNB via L2 U2N relay) to increase transmit power and / or steer signal beams and / or increase 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 in a transmission signal used to communicate with the energy harvesting device, for example, when it has an upcoming signal / message to send with high importance or certain latency requirements. To this end, a tag report message 430 or other message sent to the network or to another device may include or indicate the (estimated) or last known location of the low power tag device, a priority indication, a message type (e.g., an emergency SMS), a delay / latency indication, the energy harvesting capabilities of the device (e.g., a frequency range for RF-based energy harvesting), a remaining energy budget (e.g., a battery level), an energy budget for sending or receiving subsequent messages (e.g., an amount in Joules or a similar unit of measurement), a request for an amount of energy (e.g., RF-based) to be supplied, an estimated time (e.g., under current conditions, or calculated based on its requested or desired energy level) when sufficient energy is expected to be available to receive or send subsequent messages (e.g., based on preconfiguration information (e.g., a minimum or maximum amount of energy that can be supplied, and / or an amount of energy for a specific energy density of an RF signal in a specific frequency) or based on historical data) to be supplied by other nodes or base stations during a period of time (which can be preconfigured). Based on such a request, the network (e.g., gNB 421) and / or another device (e.g., UE 460) may adjust its transmission scheme (e.g., by directing a high energy signal beam in the direction of the energy harvesting device). The energy harvesting device may adjust its antenna / radio configuration after it has sent such a request.

[0220] In one example, the energy harvesting device may include an indication of one or more high priority messages to be sent (e.g., by including an emergency flag in a tag report, or by including an identifier indicating the use of emergency services (e.g., a relay service code) in a sidelink discovery / multicast / broadcast or other sidelink message) and / or by sending an RRC message, MAC control element, or dedicated buffer status report or scheduling request indicating that a high priority message is to be sent to another device (e.g., UE 460 or Gnb 421). The message including such a high priority indication may be the message itself (e.g., so as not to waste unnecessary energy and because the energy harvesting device may have additional high priority messages to send). Upon receiving such an indication, the other device may include this high priority indication in a message that it forwards or sends to another node after receiving the message from the energy harvesting device. In addition, the other device may increase the transmit 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 send another type of high energy signal (e.g., based on Qi or other wireless power standards) in the direction of the energy harvesting device. In addition, another device may increase the transmit 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 send another type of high energy signal (e.g., based on Qi or other wireless power standards) in the direction of other nodes involved in the forwarding message from / to the energy collection device, and the other nodes have indicated (e.g., in the aggregate message) that they also collect energy. In addition or alternatively, another device may request to forward / forward from the energy collection device or other nodes near the energy collection device to other nodes involved in the energy collection device or other nodes near the energy collection device to transmit 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 send another type of high energy signal (e.g., based on Qi or other wireless power standards) in the direction of the energy collection device. To achieve this, another device may send a message including location information of the energy collection device (e.g., distance and / or angle information and / or estimated geographic location), based on which the other nodes can determine the angle of beamforming in the direction of the energy collection device. The other device may also include a time schedule or other configuration information (e.g., a frequency band or signal type to use) that the node can use to determine when and how to send a high energy signal in the direction of the energy harvesting device. The other device may also send such a time schedule and / or configuration information to the energy harvesting device that has a high priority message to send, so that the energy harvesting device can adjust its antenna / radio configuration based on the received time schedule and / or configuration information.

[0221] In additional embodiments (which may be implemented independently), to facilitate beam steering or scheduling or configuration of RF-based energy supply to an energy harvesting device, a tag and / or energy harvesting device may provide feedback about received beams in a simplified manner (i.e., due to limited processing capabilities of the tag or energy harvesting device) by including a flag / attribute in a tag report or other message indicating that it has received additional energy for collection (e.g., at a scheduled time or a time that it may report in a tag report or other message), and / or including in a tag report or other message information about the amount of energy received (e.g., energy budget / battery charge difference) since a preconfigured time or reference time (e.g., indicated in an RRC measurement configuration message) or a scheduled time (e.g., using a time schedule as described above) or since its last message was sent or received, or within a preconfigured time period, or within a time period indicated by a set of timestamps added to the report, and / or information about the amount of energy it received at a particular time or measured within a time period (e.g., measured in joules per second or a similar unit of measurement), and / or a beam index (e.g., an SSB index) of one or more of the strongest beams that may be measured during a preconfigured time period. In an option, timestamps (e.g., timestamps of receiving energy, performing measurements, generating reports, sending / receiving messages) may be omitted from tag reports or other messages sent by tags and / or energy harvesting devices if the time corresponds / matches (possibly with small allowed / preconfigured variations) to preconfigured times, such as the time since a reference time (such as the time or time offset since the last message (such as a SIB or downlink message) was received or since the last message was sent). Alternatively, it may send an index to a set of preconfigured times (e.g., whereby each index may indicate a different time offset, or indicate a different reference time, or indicate a different reference signal that may be received by the energy harvesting device, such as a downlink signal containing a certain flag or attribute value).

[0222] In other words, a wireless communication device (e.g., a UE or an access SV) may be adapted to obtain an indication that a second wireless communication device (e.g., a tag) is capable of energy harvesting (e.g., by receiving a message from the second wireless communication device including a flag or attribute indicating such capability or by obtaining such information from subscription or capability information associated with the identity of the second wireless communication device stored in the wireless network), and 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 send a high energy signal / beam in the direction of the second wireless communication device.

[0223] Such a wireless communication device may be further adapted to obtain the angle by performing angle-of-arrival measurements on a message received from the second wireless communication device and / or by determining the angle (and / or distance) between the wireless communication device and the second wireless communication device based on an estimated position of the wireless communication device and / or the second wireless communication device.

[0224] Such a wireless communication device may be further adapted to receive a message from a second wireless communication device regarding a high priority message to be sent by the second wireless communication device (whereby the message received from the second wireless communication device may be the high priority message itself), and determine whether to send a high energy signal / beam in the direction of the second wireless communication device based on the priority of the message.

[0225] Such a wireless communication device may be further adapted to send a message to a third wireless communication device containing one or more of the following information, which the third wireless communication device may use to determine whether to supply energy to the wireless communication device and / or the second wireless communication device:

[0226] – an indication of energy harvesting capabilities of the second wireless communication device,

[0227] – an indication of the energy harvesting capabilities of a wireless communication device,

[0228] - angle, distance or (relative) position information related to the wireless communication device and / or the second wireless communication device,

[0229] - an indication of a high priority message to be sent by the wireless communication device and / or the second wireless communication device,

[0230] - Sending a request for a high energy beam to the wireless communication device and / or the second wireless communication device, whereby such a request may include timing and / or configuration information.

[0231] Such a wireless communication device may be further adapted to send a message to the second wireless communication device comprising information about the capability to provide energy to the second wireless communication device.

[0232] In addition, the second wireless communication device (e.g., a tag) can have energy harvesting storage capabilities (e.g., a capacitor) and can be adapted to include an indication that the second wireless communication device is capable of energy harvesting in a field / attribute of a tag report message and can be adapted to configure a wireless receiver operated by the second wireless communication device to receive high energy signals / beams for energy harvesting.

[0233] The second wireless communication device may be adapted to include in a field / attribute of the tag report message information about the amount of energy that has been received since a preconfigured time or reference time or during a preconfigured or reference time interval.

[0234] Backscatter communication

[0235] In an additional embodiment that can be used independently or in combination with other embodiments, the low power tag device can use the concept of RF backscatter communication to send a safety report message as part of RAN1030 via a reflected RF signal from an access device (e.g., a base station or communication device providing sidelink service). To this end, the above-mentioned system / method / device for generating a signal toward an energy harvesting device can be applied to generate a backscatter communication signal toward a backscatter communication device, whereby "energy harvesting device" is replaced by "backscatter communication device" and "energy harvesting capability" is replaced by "backscatter communication capability". Additionally or alternatively, the impact signal may include a type identifier field to indicate the type of identifier in the identifier field (device identifier or device group identifier), and the identifier field may contain an identifier of an individual low power tag device and / or an identifier of a group of low power tag devices. For example, this can be one of the temporary identifiers (temp-id) preconfigured on the tag device as described in other embodiments, or a portion thereof (e.g., a predetermined / preconfigured number of bits / bytes of an identifier or temporary identifier value to be matched). The tag device can determine whether to send / modulate a response as part of the impact signal by checking whether the identifier in the impact signal matches one of these preconfigured temporary identities (or a portion thereof).

[0236] Example deployment of a positioning system

[0237] In an exemplary embodiment of the present invention, Figure 5 Schematically shows the Figure 4An example deployment of a location system of the system architecture 400. The deployment in a 2D plane within an X / Y coordinate system shows anchor nodes such as gNBs 521, 522, 523, 524 (represented by large circles) as 5G NR base stations, SL-UEs 561, 562 (represented by rectangles), which are UEs more powerful than tags and passing through the coverage area, OoC tags 511, 512, 513 (represented by small solid circles) and coverage tags 501, 502, 503 (represented by small hollow circles). The SL-UEs 561, 562 and tags 501, 502, 503, 511, 512, 513 are capable of NR sidelink communication and are also capable of sending / receiving sidelink discovery or sidelink multicast / broadcast messages according to 3GPP TS 38.300 (Release 16). Unlike tags 501, 502, 503, 511, 512, 513, SL-UE 561, 562 can also implement sidelink synchronization signal transmission according to 3GPP TS 38.331 (version 16), 3GPP TS 38.300 (version 16), 3GPP TS 38.211 (version 16) and 3GPP TS 38.213 (version 16). Therefore, SL UE 561, 562 can act as SyncRef UE. As shown by the arrows, tags 501, 502, 503 within the coverage range can send tag report messages to multiple gNBs 521, 522, 523, 524. Although not shown, it should be noted that tags 501, 502, 503, 511, 512, 513 can also send tag targeting directly to gNBs 521, 522, 523, 524 in a secure unicast manner due to being within the coverage of the gNB. As shown by the arrows, a tag report message can be sent from a tag (e.g., 501) and received by a peer tag (e.g., 511). Based on receiving the tag report, the peer tag can create a tag targeting by combining information from the received tag report with specific metadata describing the event of the receipt of the tag report. The same process applies to a peer tag (e.g., 511) sending a tag report received by a tag (e.g., 501). Therefore, the process works in both directions, as shown by the double-headed arrow connecting the small circles. Note that a single tag report sent by a tag (e.g., 501) that covers one or more anchor nodes (e.g., gNBs 521, 522) is received by the peer tags (e.g., 511, 512) in range as well as the anchor nodes. The dashed arrows show the SL synchronization signals 531, 532, 533 sent from the SL-UE 561, 562 as SyncRef UE to the tags 511, 512, 513, which in particular can be used as time reference instead of the OoC tags using the time reference from the gNB.The dotted lines "Uu" 570-a, 570-b indicate that the SL-UE 561, 562 are optionally also connected to and cover the gNBs 521, 522 (connections between gNB 521 and SL-UE 561 and between gNB 522 and SL-UE 562). It is worth noting that when not within the gNB coverage, the SL-UE can act as a SyncRef UE under specific conditions defined in Section 5.8 of TS 38.331. In addition, when within the gNB coverage, the SL-UE can act as a SyncRef UE under specific conditions. In an optional embodiment, a SL-UE within the gNB coverage but away from the gNB (for example, determined by signal quality or signal level measurement and then comparison with a threshold) is allowed to send sidelink synchronization signals to help nearby OoC tags synchronize their internal time references.

[0238] direct communication

[0239] Figure 8 The signaling and processing diagram of the communication process between the access device and the tag according to an embodiment of the present invention is schematically shown. In an embodiment that can be combined with other embodiments or used independently, the access device 831 (e.g., a base station or a communication device providing a sidelink service) as part of the radio access network (RAN) 830 sends a request 851 for retrieving the identity or location of the tag to the communication device 801, 811 as a tag. These requests 851 can be, for example, synchronization signals (e.g., MIB) and system information (e.g., SIB1), which give an indication of the ability to read the tag. These requests may be independent signaling messages of the tag. This capability can be indicated by using a specific closed access group (CAG) identity or any other identifier (e.g., group ID) with a similar purpose. After receiving the corresponding request 851, the communication device 801, 811 can send a corresponding reply 852 (as described in other embodiments of the present invention) to the access device 831 to provide their identity and / or location information. Then, the access device 831 can forward the corresponding reply 852 to another entity in the core network (CN) 840, such as a server 841 providing positioning services.

[0240] In case the access device 831 is a base station, the reply 852 may be an initial Physical Random Access Channel (PRACH) enhanced to directly include the (protected) identity of the communication device 801, 811, thereby avoiding further round trips and / or energy consumption.

[0241] In the case where the access device 831 is a communication device providing sidelink service, the request 851 can be, for example, a sidelink synchronization signal or a notification discovery message or a sidelink broadcast / multicast message, and the reply 852 can be a discovery message or a sidelink broadcast / unicast message.

[0242] In one embodiment, the access device 831 may filter or limit the number of forwarded responses 852 based on the CAG or related identifier used, or based on the identity or location of the communication device.

[0243] Fig. 9 The signaling and processing diagram between the access device and the tag involving the authentication process between the network and the tag according to an embodiment of the present invention is schematically shown. In an embodiment that can be combined with other embodiments, the access device 931 (e.g., a base station) as part of the RAN 930 sends a request 951 for retrieving the identity or location of the communication device 901. These requests 951 can be synchronization signals (e.g., MIB) and system information (e.g., SIB1) that gives an indication of the ability to read tags. This ability can be indicated by using a specific CAG identity or any other identifier with a similar purpose (e.g., a group ID). The communication device 901 can send a random access request 952 as a reply when receiving the request 951. The access device 931 can allocate a temporary RAN identity 953 to the communication device 901. The communication device 901 can send an identification request / network access request / positioning request 954 to the CN 940 through the access device 931, where the identity can be protected as described in other exemplary embodiments of the present invention or as a 5G SUCI. The message can also include other features / sensing data stored / measured by 901. The identity or such features / sensing data may be sent as part of a tag report, as described in other embodiments of the present invention, to allow the network to identify the tag and / or monitor / track it. The tag report may also be part of this message. Upon successful identification, the network may use this message to determine the location of a given tag. The CN 940 (and / or a server 941 providing positioning services) may obtain a rough estimate of the location of the communication device 901 based on the access device 931 involved.

[0244] Optionally, a subsequent authentication process (955, 956) between the communication device 901 and the CN may be performed, for example, based on the level of trust that the CN 940 has on the message 954. The authentication process may be based on the primary authentication.

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

[0246] This process is advantageous because the access device can request / retrieve the identification / characteristic / sensing data of the tag device 901 with minimal interaction.

[0247] Fig.10 A signaling and processing diagram between an access device and a tag according to an embodiment of the present invention is schematically shown, wherein a tag within coverage rebroadcasts a request from an access device. In an embodiment that can be combined with other embodiments, an access device 1031 (e.g., a base station or a communication device providing a sidelink service) as part of a RAN 1030 sends a request 1051 for retrieving the identity or location or data of a communication device (1001, 1011). These requests 1051 can be synchronization signals (e.g., MIB) and system information (e.g., SIB1) that gives an indication of the ability to read tags. This ability can be indicated by using a specific CAG identity. Communication device 1001 is within range, but communication device 1011 is not within range. The communication device may have been configured with a policy requiring rebroadcast of the request 1051, or the request itself may include this command. The request may include a parameter indicating how many times the request is to be rebroadcast, and the rebroadcasting communication device 1001 may reduce the parameter each time it is rebroadcasted. The rebroadcast request 1052 may arrive at the communication device 1011, which may prepare its report as described in other example embodiments of the present invention, and may then send a reply 1055. The communication device 1001 may wait for a maximum time to receive a second report 1055 from a second communication device (e.g., 1011) that may not be in coverage. If the second report 1055 arrives before the rebroadcast request 1052 arrives, the communication device 1001 may calculate its own report, including the second received report 1056, and send a combined report 1057 to the access device 1031 of the RAN 1030. The access device 1031 may forward the reply in a message 1058 to another entity in the core network 1040, such as a server 1041 providing positioning services.

[0248] In an embodiment that can be combined with or independent of other embodiments, the communication device's reply (e.g. Figure 8 852 in ) can be sent at a timing and using a frequency resource determined by an identity (e.g., an identity of the communication device) or a protected (hashed, encrypted) identity of the communication device, or depending on the beam used to access the communication device. This is in Fig.11, where the horizontal axis represents timing resources and the vertical axis represents frequency resources, and the blocks in the grid represent the same time / frequency resource. This may be multiple carriers used to send orthogonal frequency division multiplexing (OFDM) symbols. Devices (1101, 1111, 1112, 1121) are assigned to different blocks. Given a resource block, a device may need to listen (for other transmissions) before sending a reply, and / or wait for a random time within the block before sending, and / or wait for a period of time (in discrete steps) before sending. This has the advantage that a single access device can handle a larger number of tags.

[0249] In an embodiment that can be combined with other embodiments or used independently, the request message (e.g. Figure 8 The message 851 in may include a communication device (e.g. Figure 8 Configuration of a time window or frequency resource set that may be used by device 801 in.

[0250] In an embodiment that can be independently combined with other embodiments, the communication device (e.g. Figure 8 Configuration of a time window or frequency resource set that may be used by device 801 in.

[0251] In a variant embodiment, the device (e.g., 801) may determine a possible set of resources based on the initial message 851, for example, MIB / SIB1 may implicitly / explicitly determine / indicate the resource or resource set used in the random access process. The device 801 may then further select a specific resource / resource set to be used based on its own identity, for example, the specific resource is a function of its identity, or any other device parameter (e.g., tag type, physical location), or other implicit / explicit indication.

[0252] Repeated transmission and data replication

[0253] In an additional embodiment that can be used independently or in combination with other embodiments, the communication device can receive a configuration regarding support for repeated transmission and / or data duplication (e.g., SIB broadcast, RRC configuration) from an access device. In the case of repeated transmission, the communication device can receive a configuration of the number of repeated transmissions N (N>=1) from the access device, and then in the actual transmission of the security report message, the communication device can repeatedly send data N times in the physical / MAC layer that can be multiplexed in the time, frequency and / or space domains. The receiving end of the repeated transmission at the access device can (partially or completely) combine the copies of the received physical packets, and can apply joint decoding to the packets to extract the security report message. In the case of data duplication, the communication device can receive a configuration of how repeated data can be sent in an application layer (such as a PDCP and / or RLC layer), and then in the actual transmission of the security report message, the communication device can use one or more RLC entities to send the same PDCP packet, and detect / discard the duplicated PDCP packet at the receiving end (e.g., at the receiving communication device or at the access device).

[0254] Energy harvesting / transfer scheme

[0255] In an additional embodiment that can be used independently or in combination with other embodiments, a node in a wireless network (e.g., a low-power tag device or a UE or a separate RF energy supply unit) receives a resource allocation message (e.g., RRC signaling, DCI / SCI message, MAC control element) from an access device 1031 (e.g., a base station) that is part of the RAN 1030 or from a UE or other communication device that can provide a sidelink service (e.g., SL-UE 460), wherein the resource allocation message indicates that energy is sent to a nearby energy collection device (e.g., a low-power tag device) at a specific time interval, whereby the energy sent can be an RF signal within a preconfigured frequency range (e.g., 80kHz to 300kHz for Qi, or using a 4G / 5G cellular band or an IMT unlicensed band, such as a band that can be sent at a high transmit power) and a (pre) configured transmit power selected / requested / preferred by the low-power tag device. The resource allocation message may also indicate frequency range information, beam direction information, and transmit power information. Such information may also have been preconfigured using an earlier message (e.g., an RRC message or SIB) sent to the corresponding node. An access device 1031 (e.g., a base station) as part of the RAN 1030, or a UE or other communication device that can provide a sidelink service can schedule similar resources to an energy collection device (e.g., a low-power tag device) to receive corresponding energy. An access device 1031 as part of the RAN 1030, or a UE or other communication device that can provide a sidelink service can schedule resources differently depending on the distance, angle, relative position of the access device and the energy collection device, and / or the amount of communication devices near the energy collection device that can assist in sending high-energy signals / beams to the energy collection device and / or provide a sidelink service to communicate with the energy collection device, and / or the amount of other energy collection devices near the access device. The resource configuration can include multiple different resource scheduling and / or the access device 1031, or the UE or other communication device that can provide a sidelink service can select different energy transmission parameters (e.g., transmit power), and the access device 1031, UE or other communication device that can provide a sidelink service can select these parameters based on the measured / estimated distance, the angle between the communication device providing the sidelink service and the nearby energy collection device (e.g., a low-power tag device). The access device 1031, or UE, or other communication device that can provide sidelink services can receive a message (e.g., an aggregate tag report / signaling message) that contains information about the energy collection capabilities of the energy collection device and intermediate nodes that are involved in forwarding messages from the energy collection device to the access device 1031, or UE, or other communication device that can provide sidelink services, and / or angle / distance / position information related to these devices and the energy collection device.

[0256] In one example, the resource allocation message is a dedicated DCI / SCI format / type for scheduling signals related to energy collection. In a specific example, a first communication device capable of sidelink communication sends a dedicated SCI to request a second communication device on the sidelink communication to send a high energy signal to the first communication device. The request may include information about timing, frequency, and priority. The second communication device may respond with another SCI to confirm that it will send a high energy signal to the first communication device. The response may include information about timing and frequency information related to the high energy signal that the second communication device will send to the first communication device.

[0257] Similarly, as previously described, a tag and / or energy collection device or intermediate node that receives energy based on this type of resource allocation scheduling (e.g., as a first communication device mentioned in the previous paragraph) can provide feedback about the received energy, for example by including a flag / attribute in a tag report or other message indicating that it has received additional energy for collection (e.g., at a scheduled time or a time that it can report in a tag report or other message), and / or including in a tag report or other message information about the amount of energy received (e.g., energy budget / battery charge difference) since a preconfigured time (e.g., the time when resources were allocated) or a scheduled time (e.g., as a resource allocation schedule mentioned above) or since its last message was sent or received, or within a preconfigured time period, or within a time period indicated by a set of timestamps added to the report, and / or information about the amount of energy it received at a particular time or measured within a time period (e.g., measured in joules per second or a similar unit of measurement).

[0258] In other words, a wireless communication device (e.g., a UE or an access device) can be adapted to obtain an indication that a second wireless communication is capable of energy harvesting (e.g., by receiving a message from the second wireless communication device including a flag or attribute indicating such capability, or by obtaining such information from subscription or capability information associated with the identity of the second wireless communication device stored in the wireless network), and to schedule resources of the second wireless communication device or a third wireless communication device, which the second wireless communication device or the third wireless communication device can use to configure a wireless receiver operated by the wireless communication device to receive a high energy signal / beam and use it to harvest energy and / or to configure a wireless transmitter operated by the wireless communication to send a high energy signal / beam to an energy harvesting device.

[0259] Wake-up signal for energy harvesting low-power tag devices

[0260] In an additional embodiment that can be used independently or in combination with other embodiments, the low power tag device receives a wake-up signal from an access device 1031 (e.g., a base station or communication device providing a sidelink service) that is part of the RAN 1030 to wake up the energy collection device (e.g., the low power tag device) and / or the energy collection device group (e.g., the low power tag device) to make it suitable for collecting energy from an external source (also called an ambient source) and / or sending a first safety report message. The wake-up signal may include a device identifier and / or a device group identifier for triggering the device and / or a group of devices to start the energy collection process and send / receive a safety report message.

[0261] In additional embodiments that may be used independently or in combination with other embodiments, the low power tag device may be configured to periodically wake up to detect the presence of a wake-up signal potentially transmitted at a specific time (e.g., frame / subframe / time slot / symbol) and frequency. The randomization may be performed differently for each energy harvesting device and / or each group of energy harvesting devices based on a device identifier of the energy harvesting device (e.g., a low power tag device) and / or a device group identifier in a group of energy harvesting devices (e.g., a low power tag device). The specific frequency resources used to send the wake-up signal may be fixed or may be based on a preconfigured frequency hopping pattern to exploit the diversity of the wireless channel. Fig.12 In the example, energy harvesting devices (e.g., low power tag devices) 1201 and 1202 can periodically wake up at each configured time and frequency in the resource grid to detect the presence of a wake-up signal sent by the access device 1031. If a wake-up signal is detected, the device can further decode the content of the wake-up signal packet for further processing; if no wake-up signal is detected, the device can turn off the radio transceiver and return to sleep mode until the next wake-up opportunity pre-configured by the access device.

[0262] The wake-up signal can use a multi-carrier OOK (on-off keying) scheme similar to that defined in IEEE 802.11ba-2021. In addition, the wake-up signal can also use a multi-carrier ASK (amplitude shift keying) scheme, a multi-carrier FSK (frequency shift keying) scheme, or a CP-OFDMA (cyclic prefix-orthogonal frequency division multiplexing access) scheme. The wake-up signal can be embedded in the 4G / 5G OFDMA downlink resource grid, with guard bands at both ends of the wake-up signal frequency band, and guard times at either or both ends of the wake-up signal in the time domain to compensate for the low accuracy of time / frequency synchronization between the wake-up signal and the network. Low-power tag devices can use synchronization signals (SSB, PSS / SSS / PBCH) from the base station and / or from the SL SyncRef The access device may additionally send a low-power synchronization signal (LP-SS) for low-power tag devices to track the network time / frequency, so that low-power tag devices with low-cost clocks or no clocks can be fully synchronized with the access device. The wake-up signal may use a sequence-based design, such as a Zadoff-Chu sequence to represent a limited number of information bits, and / or coded bits on multiple time / frequency resources to carry a larger number of information bits. In one embodiment, the wake-up signal may be used as an impact signal for backscatter communication, and the low-power tag device may wake up immediately after receiving the impact wake-up signal, and reflect / modulate the impact signal to send a tag report message.

[0263] Fig.13An example of a wake-up signal packet is shown. In addition to the potential header and CRC fields in the packet, the packet may also have a type field to indicate the purpose of the wake-up signal, such as waking up an energy collection device (e.g., a low-power tag device) to collect energy from an external source (also referred to as an environmental source), and / or waking up an energy collection device (e.g., a low-power tag device) to receive downlink data from the access device 1031, and / or waking up an energy collection device (e.g., a low-power tag device) to send uplink data to the access device 1031; the packet may also have a type identifier field to indicate the type of identifier in the identifier field (device identifier or device group identifier), which may contain an identifier of a single energy collection device (e.g., a low-power tag device) and / or an identifier of a group of energy collection devices (e.g., a low-power tag device). For example, this may be one of the temporary identities (temp-id) preconfigured on the tag device as described in other embodiments, or a portion thereof (e.g., a predetermined / preconfigured number of bits / bytes of an identifier or temporary identity value to be matched). The tag device can determine whether to wake up by checking whether the identifier in the wake-up signal matches one of these preconfigured temporary identities (or a portion thereof). To prevent erroneous wake-up signals from being used to interfere with tag operation, the wake-up signal packet may also contain a security section data field or other fields to act as a message integrity check. When a tag receives a wake-up signal, it can calculate the security section data field using its own temporary tag ID or any other group ID assigned to it to check whether it is the intended recipient of the message. To help the tag decide which ID to use, a few bits of a "group" flag or index value may be carried in the wake-up message.

[0264] Fig.14 It can be depicted that the process of energy harvesting devices (eg, low power tag devices) 1201 and 1202 operate with a wake-up signal sent by the access device 1031. The following is a detailed description.

[0265] S1: The access device 1031 pre-configures wake-up configuration information on the energy harvesting devices (e.g., low-power tag devices) 1201 and 1202, and the wake-up configuration information may include time and frequency information for periodic wake-up to detect the presence of a wake-up signal;

[0266] S2: When the tag device wakes up at the scheduled time to detect the wake-up signal, the tag device will continue to step S3; otherwise, the tag device will remain in the sleep mode;

[0267] S3: The tag device wakes up to detect the presence of the wake-up signal;

[0268] S4: If the tag device detects the presence of the wake-up signal at the preconfigured time and frequency, the tag device will proceed to step S5; otherwise, the tag device will enter step S8 to enter the sleep mode;

[0269] S5: The tag device further decodes the content of the wake-up signal packet;

[0270] S6: If the content of the wake-up signal packet indicates that the packet is for the tag device through the device identifier or device group identifier of the device group to which the tag device belongs, the tag device will continue to step S7; otherwise, the tag device will enter the sleep mode in step S8;

[0271] S7: the tag device completes the operations required for accessing the device 1031, and then proceeds to step S8 to enter the sleep mode;

[0272] S8: The tag device enters sleep mode.

[0273] In some cases, conventional processing of the wake-up message may be too energy intensive for the tag device, and / or in some cases, the tag device may not be able to track time as in some embodiments of the present invention. In some cases, the tag device may not be able to wake up to monitor, for example, the presence of a sync signal / MIB / etc. from an access device as in some embodiments of the present invention. In these cases, another embodiment of the present invention is applicable, in which an initial message may be sent such that it provides sufficient energy for the tag device to decide to operate, for example Fig.14 The initial process or execution in Figure 8 The tag device uses this initial message to check if a wakeup / reply is requested. Once this is checked in the affirmative, the tag can use energy from its own energy supply (e.g. harvested energy). For example, a tag device with a photodetector / small solar panel (e.g. energy harvesting device from light) can also use this energy harvesting device to receive the initial message (light encoding) which indicates to perform Fig.14 and / or Figure 8 Thus, the initial message can be powered by the incident light source and the tag device consumes no energy. If the initial message includes a given identifier, or can be successfully verified (for example, if it includes a MIC), the tag device can proceed to further steps, for example, according to Figure 8 or Fig.14 ,These steps may require energy consumption from the device tag.

[0274] In an embodiment variant, the reception of this initial message may also be used as a timing reference, for example, similar to a synchronization signal indicating when a subsequent message may be received, for example Fig.14 The wake-up signal shown or Figure 8 SIB1 is shown. This is advantageous because the tag device does not need to keep track of the time to perform the actual wake-up operation.

[0275] In one embodiment variation, the initial message may be a physical layer message, where the device tag only needs to monitor some specific physical properties of the signal, such as whether the signal is modulated at a specific frequency or follows a given pattern at the modulated frequency. For example, a light source may be modulated (e.g., by switching on and off at a frequency fc for amplitude modulation), and this modulation may be detected from a photodetector.

[0276] In one embodiment variation, the receipt of the initial message implicitly configures the tag device with configuration information (eg, regarding timing and / or frequency resources) to send a tag report and / or triggers the tag device to send a tag report.

[0277] In an embodiment that can be combined with other embodiments or implemented independently, an access device or UE or intermediate node capable of supplying an energy collection signal to an energy collection device (e.g., a low-power tag device described in the present patent application) can use different types of energy collection signals, wherein a first type of energy collection signal can be used to supply energy to the energy collection device (e.g., by using a high energy beam) without requesting the device to wake up, and a second type of energy collection signal can be used to supply energy to the energy collection device (e.g., by using a high energy beam), thereby triggering the energy collection device to wake up immediately after collecting enough energy or within a predetermined / preconfigured time. To this end, the second type of energy collection signal can use a specific frequency or frequency shift or some signal peaks or signal patterns, or have other detectable signal features that can be distinguished from the first type of energy collection signal by the receiving energy collection device. The energy collection device can determine that the device can continue to sleep (also after it has collected enough energy) when receiving the energy collection signal from the first type, or determine that the device needs to wake up if possible (e.g., immediately after it has collected enough energy or within a predetermined / preconfigured time after it has collected enough energy) when receiving the energy collection signal from the second type.

[0278] Clock synchronization based on gNB and sidelink

[0279] In further detail, OoC tags are synchronized with the sidelink synchronization signal transmitted by the corresponding nearby SL-UE, while in-coverage tags are synchronized with the synchronization signal (sync signal) transmitted by the gNB. Due to the way the SL synchronization process is defined in 3GPP TS 38.331 (Release 16), when the SL-UE is within the coverage of the gNB, the synchronization signal (SLsync signal) transmitted by the SL-UE will be synchronized with the gNB timing. Alternatively, if the SL-UE is OoC to the gNB, it can also use a GNSS (e.g., GPS) based timing reference if it has this component GNSS integrated, so that it will also time synchronize to all nearby gNBs whose timing is also based on the Coordinated Universal Time (UTC) reference time. This time synchronization of tags allows tags in the coverage area (i.e., tags in the coverage of a gNB or a gNB-connected SL SyncRef (synchronization reference) UE) to use a common time reference and therefore unambiguously determine the time windows for tag report transmission and reception.

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

[0281] In an optional embodiment, the low power synchronization signal that the wake-up radio receiver in the low power tag device keeps track of the time / frequency of the network used for wake-up signal detection / decoding can also be used for clock synchronization of the low power tag device.

[0282] Sending tag reports without clock synchronization / reference signal

[0283] In an example scenario where the OoC tag does not find a gNB or SL SyncRef signal as a basis for its time window calculation, the OoC tag may still send its tag report using an alternative method. In this case, the OoC tag may listen to the tag report sent by a nearby tag that is within the coverage of the gNB or SL-UE (i.e., the nearby tag can receive synchronization signals from the gNB or SL-UE). Then, upon receiving this tag report, the OoC tag may immediately send its own tag report on the same frequency / channel resource and may also be based on the configuration data included in the received tag report. This method is effective if the indicated frequency / channel resource is 100% available in general SL or specific tag transmission, i.e., it is not time multiplexed with other purposes of cellular communication such as uplink (UL) / downlink (DL). Using this method, the tag report of the OoC tag is likely to be transmitted within the allocated time window, so this information can still be used for OoC tag location determination as described in the present invention. The advantage of this method is that the system becomes more robust to coverage loss and loss of temporary synchronization sources (e.g., based on SL-UE).

[0284] In an alternative example approach, the OoC tag may also perform a transmission time calculation based on multiple tag reports received from nearby tags. That is, when an OoC situation without a synchronization signal is detected, the tag may cause its radio unit to receive one or more tag reports over a longer period of time, and infer and configure the time window and frequency used from this, where the time window is an approximate value. For example, if such an OoC tag receives a tag report at time t1, where the configuration data (config-data) indicates that the sleep period (during which the radio transceiver is disabled) during which the tag sends the tag report is 30 minutes, and the time window duration is 10 seconds, then the OoC tag may sleep for about 29:49 minutes and then turn on its radio unit to receive the next tag report or series of tag reports in the next period of time >11 seconds. The OoC tag may configure its timing in a way that does not miss the next time window based on the received configuration and its own estimate of its own internal clock drift / inaccuracy. In this alternative example approach, the maximum estimated clock drift of the tag during the entire sleep period is 1 second, so that it can sleep for 29:49 minutes before needing to enable its radio receiver again. With a perfect drift-free internal clock, an OoC tag can sleep for 29:50 minutes. After one or several such periods, the OoC tag is well synchronized with the time windows used by other tags in the coverage area, even without an external time synchronization signal. It is worth noting that this approach works best if the OoC tag is able (and allowed) to send data in a non-slotted manner in this case, rather than the usual slotted communication method defined by existing 5G NR UL / DL / SL communications.

[0285] exist Figure 4 In another example scenario where there is no SL-UE in the system architecture 400, the OoC tag cannot deduce with sufficient accuracy the time window during which it needs to transmit because it can no longer see any timing reference or synchronization signal from the "lost" SL-UE. In this scenario, the OoC tag may stop transmitting until it can synchronize with the timing reference again.

[0286] In another alternative example scenario where a tag is configured (e.g., directly by the gNB via DL) to act as a synchronization source for an OoC tag (note that this need not necessarily be a 5G NR SL synchronization signal; e.g., it could be a new one that is more lightweight and power efficient), then the tag as synchronization source may perform one or more of the following steps:

[0287] - Sending an additional tag report message at a predefined time (e.g. at the beginning or end of a time window);

[0288] - Include additional synchronization / time data in the tag report message that can be read by any other tag. When the additional synchronization / time data is triggered, it is not necessary to always include the additional synchronization / time data;

[0289] - Sending a specific (new) type of synchronization signal, either in an adjacent RF channel, or on the same channel, periodically during the time window duration.

[0290] Note that internal clock drift can be estimated based on known inaccuracies of the tag's timing circuitry (e.g., a crystal oscillator). Making an accurate estimate of drift may require measuring circuit temperature, since the maximum inaccuracy is expected to depend on temperature. If no temperature measurement is available, then a worst-case assumption of temperature based on the tag's valid temperature range can be used.

[0291] An alternative example method for clock drift detection and correction may be to have in-coverage tags include within their own tag reports a timestamp in a format that the received OoC tag can parse (e.g., unencrypted or encrypted with a known multicast key). Such a timestamp would allow the receiver to calibrate its own clock and at the same time calculate an estimate of the clock drift since the last time the timestamp was received. This estimate can then be used to adapt the receive window, as indicated by the "11 seconds" in the example above. For example, with a more accurate drift estimate, an OoC tag may listen for only a 10.4 second time window instead of an 11 second window, thereby saving energy on the tag.

[0292] The OoC tag may then also mark the transmission of its tag report message as a special "out-of-sync override" in the common data portion of the tag report message, e.g. with a bit flag, to ensure that other OoC tags do not use its transmission as a reference again. Furthermore, since the OoC tag does not receive a timestamp format based on the system frame number (SFN), the OoC tag cannot use a timestamp format based on the system frame number (SFN). Therefore, the OoC tag may advantageously indicate another timestamp format in its own tag report message, e.g., an estimated SFN, or just an internal sequence number (ISN).

[0293] Time synchronization of tags using collective / shared tag reporting time windows

[0294] In an example embodiment, based on a "configuration data" parameter distributed by the gNB as configuration data to all in-coverage tags, tags may select a time window during which to send and receive tag report messages. In one example, all gNBs may periodically send this configuration information in a System Information Block (SIB) data structure. A sidelink UE or relay UE acting as a SyncRefUE may also periodically send this SIB data to allow any out-of-coverage remote UEs and tags to use it. In-coverage tags may repeat the received configuration data as a single "configuration data" element in their own tag report messages, allowing out-of-coverage tags to also receive the configuration information. Similarly, out-of-coverage tags that receive this configuration information may again include the "configuration data" element in their own tag report messages, so that additional out-of-coverage tags may also receive the relevant configuration. This may be done all the time in an alternative embodiment, while in another alternative embodiment, this is done only based on the result of a decision algorithm. For example, when there is not enough space in a tag report message to include a configuration, the configuration may not be included, but may be included in some other way. Alternatively, as another example embodiment, the configuration may be included only when the configuration bit (flag) indicates "configuration data" for tag reporting including OoC tags, and when there is enough space in the tag report message. It is worth noting that the size of the tag report message may depend on the number of tag sightings included and other factors.

[0295] exist Figure 4 In an example embodiment, the tag may select a random time within the time window to transmit and attempt a sidelink discovery message broadcast transmission at the selected moment. Based on the existing 3GPP NR V2X Mode 2 (i.e., resource selection mode 2 specified for NR SL communication), if there are no idle resources at the original moment, a suitable "idle" resource will be selected at that moment or the next moment. In the event that a tag detects that its transmission interferes with another transmission or is very close in time to another transmission, the tag may randomly select a new idle time slot to use it to repeat its tag report transmission. The tag may also select a new channel within the same time slot to repeat its tag report transmission on the new channel. This embodiment attempts to keep the length of the tag's Rx time window to a minimum while allowing the density of tags in a geographic area and / or the number of tag report messages to still scale dynamically.

[0296] Embed configuration data in sync / reference signals

[0297] In an example embodiment, a synchronization signal used by a tag to determine its transmission timing may be used to embed a few bits of configuration data ("Configuration Data") from which the tag can decode. The synchronization signal may be a SyncRef SL signal sent by the UE, or may be a synchronization signal sent by the gNB, or both. This may be useful in situations where the tag does not want to expend energy to receive and decode the full RAN Configuration Data broadcast as part of the Master Information Block (MIB) / System Information Block (SIB).

[0298] Message Type for Tag Reporting - ProSe PC5 Direct Discovery Message

[0299] In an example embodiment of the present invention, the message used for tag reporting can be a ProSe PC5 Direct Discovery message type of 3GPP TS24.554 (Release 17). It can use "open discovery" (e.g., "Open 5G ProSe Direct Discovery Announcement") for which all tags in a region can participate in the protocol, or it can also use "restricted discovery" if specific key material is pre-installed in each tag of a collaborative group of tags while excluding any tags from other groups. It is worth noting that the term "group" of tags can even refer to all tags in a region / country, or a group of tags owned by a specific organization, or tags that implement a specific application standard, etc.

[0300] "Open Discovery" can be used with or without additional cryptographic protection. In this disclosure, no additional cryptographic protection is required only for the sake of simplicity.

[0301] Note that in the current ProSe specification, discovery message reception is typically followed by the selection of a suitable (discovered) candidate UE, which is then initiated with a communication link using a ProSe Direct Communication Request (DCR) with that candidate UE. The current discovery messages defined for positioning do not use this DCR. From a tag perspective, this is subtle, as it is most likely that even DCR and ProSe PC5 direct communication will not be typically implemented. In fact, it only uses discovery messages to transmit tag reports. For the SL-UE to receive tag reports, its UE (pre) configuration needs to be specifically set up to operate the UE as an "anchor point", which collects tag reports and then sends tag targeting to the network without triggering a DCR for the tag, which would be meaningless. This can be easily configured based on specific attributes of the discovery message (e.g., a specific relay service code (RSC) or RSC set), which is only associated with positioning with the tag and is not associated with some other ProSe direct communication services that can also be implemented with the SL-UE.

[0302] Another example of an attribute of the ProSe direct discovery message is the "discovery model value" bits 1 and 2 in the header, which can be used to indicate the purpose of the message as tag reporting according to an example embodiment of the present invention. Of the four possible two-bit combinations, two are used to indicate the A / B model respectively, while other two-bit combinations can still be used for this purpose, for example, "00" can be used to indicate the tag reporting message model.

[0303] Tag report structure

[0304] In an example embodiment, a tag report or tag report message may include multiple fields for identifying a tag and helping locate the tag (including retroactively locating the tag to be useful for non-real-time location systems). The tag report may include at least the following fields:

[0305] - configuration data (config-data);

[0306] - Timestamp;

[0307] -Tx-power indication;

[0308] -Secure part data.

[0309] Furthermore, a tag report may contain a vector (or set or group) of tag sightings, including information about the tag reports that the tag observed when receiving the tag reports, i.e., each tag sighting includes data for the tag report and may include metadata associated with the tag report.

[0310] It is worth noting that the curly brackets {} in the following relations indicate a combination of data items (or parameters or elements), such as: concatenation, inclusion in a tag, length and value (TLV) structure, Abstract Syntax Notation 1 (ASN.1) structure, Concise Binary Object Representation (CBOR) object, etc. The following square brackets [] indicate optional elements, which are included only when there is related data to be transmitted in the element.

[0311] In an example embodiment, the label report may be given by the following relationship:

[0312] Tag Report =

[0313] {configuration data, timestamp, tx power, secure-section-data, [Tag-sightings]}(1)

[0314] Wherein, Tag-sightings is an optional field, which is an array of length 1, ..., N, such that Tag-sightings = {Tag-sighting-1, ..., Tag-sighting-N}. The maximum value of N can be determined as a constant suitable for a specific embodiment implementation, or can be determined algorithmically by the sender.

[0315] The format of a single basic Tag-sighting-i (where i=1, ..., N) can be given by the following relationship:

[0316] Tag-sighting-i={tx power, rx-power, timestamp, secure-section-data}(2)

[0317] It can be seen that the "configuration data" item may be removed from relation (2) of tag-sighting-i because it has already been sent once in the enclosed tag report as defined in relation (1). This significantly reduces the payload size of the tag report. All tags typically use the same configuration data "config-data" at a specific moment and for a specific location / cell. This is because this data typically does not change very often. The RAN and the core network / location service also know the currently used "config-data" value and the previously used "config-data" value because the "config-data" is configured and / or distributed by the RAN for a specific area. For example, if the configuration changes at some time T and the RAN and CN / location service receive a tag sighting performed before time T, they can infer that this was sent using the old configuration data. In the case where the RAN determines the configuration data independently of the location service, or determines the configuration data based on input parameters / data transmitted by the location service to the RAN, the RAN can inform the location service of the determined configuration data when needed or as part of the tag sighting data sent from the RAN to the location service.

[0318] "Config-data" structure

[0319] In an example embodiment, the "config-data" structure can be kept very small to reduce the payload size of the tag report and can be in an encoded form. For example, it can be 8 bits and encode the following parameters:

[0320] - The specific predefined frequency band / resource to be used (3 bits);

[0321] - Specific time schedule (5 bits),

[0322] Both of them come from a set of predefined options. Note, however, that the "config-data" structure can also use more data bits to describe a finer-grained schedule.

[0323] As an example, Table 1 below shows option settings that may be predefined for a frequency band:

[0324]

[0325] Special cases can be found for the band value: "6", where the desired band is sensed by looking for SL tag reports in all supported bands and by selecting the band where the majority of tag reports are found; and "7", where tags are prohibited from sending tag reports. The band value "4" does not define a fixed channel / RB set, but a frequency hopping sequence N, where N is defined by the time scheduling parameter.

[0326] As an example, Table II below shows a subset of option settings that may be predefined for time scheduling parameters:

[0327]

[0328] 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 TS 38.331 (Release 16)).

[0329] Coordinate tag timing by having tags learn their optimal transmission times and automatically extend time slots when needed

[0330] In an example embodiment, an additional tag timing coordination mechanism may be used to avoid that all tags in an area may start sending their tag reports at the same time, or send their tag reports within the same (limited) subset of time slots within a time window. The term "time slot" is used here to refer to a time period in a time slot wireless communication system in which a tag report message can be completely sent. In this example embodiment, it is assumed that the "time slot" is equal to the 5G NR time slot cycle. However, it is worth noting that the "time slot" is not necessarily equal to the 5G NR time slot cycle, it may be shorter (e.g., one symbol period, two symbol periods, etc.) or longer (e.g., two 5G NR time slots or longer). From the third column of the above table, it is shown that the option settings that can be predefined for the time scheduling parameters can define the "target duration" of the time window for any configuration data index value related to the time window. Therefore, each tag can initially monitor the RF messages received during this time window on the allowed channel, and then record the relative time when other messages may be received in the time window. Based on this, each tag can randomly select a time slot and a corresponding channel that is still "idle" in the target time window, that is, no transmission is received on this time slot and channel. However, if there are no idle slots, or the percentage of occupied slots is above a threshold (e.g., >90%), the tag can apply an algorithm to extend the time of the default slot and randomly select one of the idle slots within this extended slot. This slot extension may require the use of new L2 / L1 (PHY / MAC) mechanisms in 5G NR SL, as it may be different from the existing 3GPP NR V2X Mode 2 of the basic embodiment (i.e., resource allocation Mode 2 specified for NR SL communications). For example, if the existing SL Mode 2 approach is too energy-intensive and a new, more efficient scheme is needed, then this desired alternative approach may be useful. However, the slot extension itself can also be used in combination with the existing SL Mode 2 resource allocation.

[0331] Timestamp format

[0332] In an example embodiment, the timestamp format may be encoded as one of the following:

[0333] - a timestamp value (e.g., 6 bits or 10 bits) that wraps around and encodes a portion of the System Frame Number (SFN), e.g., the 6 Most Significant Bits (MSBs);

[0334] - a representation of UTC time, e.g., taking the N least significant bits of a particular encoding of UTC time, such as the number of seconds since January 1, 2022 (01-Jan-2022);

[0335] - an internal timer value (e.g. 16 bits or 32 bits) loosely synchronized with the SFN, so that the SFN is used to estimate the tag's internal clock drift and compensate for it;

[0336] - A sequence number that increases by + 1 for each tag report transmission. It can be, for example, 8 bits or 16 bits or another length, and it can wrap around to 0 after reaching a maximum value (e.g., 255).

[0337] - Lamport timestamp value or vector clock value;

[0338] - A combination of some of the above: for example, a timestamp value plus a sequence number.

[0339] Control in Tx power format and strategy

[0340] In an example embodiment, a specific Tx power control strategy may alternatively or additionally be indicated to the tag as part of the "config-data" bits. Such a strategy may control the Tx power to be used by the tag to send its tag reports. The Tx power may be a 4-bit value that refers to a predefined table of 16 possible Tx power level settings for the tag.

[0341] An example of 16 bits of "config-data" including a Tx power control policy may include:

[0342] - the specific predefined frequency band to be used (3 bits);

[0343] -Specific time schedule (8 bits);

[0344] -Tx-Power Strategy Selection (5 bits).

[0345] First, the "config-data" bit can indicate a Tx power policy that specifies a specific default Tx power level. The default value is used when the tag sighting in the time window is below a specific threshold Network Termination 1 (NT1) (i.e., tag sighting < NT1, indicating "not busy" in the local area on the RF channel / band used).

[0346] Secondly, as more tag sightings are made (i.e., tag sightings ≥ NT1, indicating "busy"), the tag can automatically reduce its Tx power by a pre-agreed amount to induce smaller tag sightings in neighboring tags, making it automatically "less busy" in the RF channel / band used in the geographic area.

[0347] Third, if the number of tag sightings is below a certain threshold Network Termination 2 (NT2) (i.e., tag sightings < NT2, indicating "I barely see anyone else"), the tag can automatically increase its Tx power by a pre-agreed amount to induce more tag sightings among neighboring tags, which is useful in sparse tag environments.

[0348] Fourth, the policy may also define what to do when it sees only tags with very low received signal strength (Rx Level) targeting, while the Tx power of these tags targeting (as indicated in the "Tx Power Indication" field) is still relatively high. The tag can then infer that it is away from all other tags, and therefore increase its Tx power by a certain amount determined by the policy.

[0349] Rx-Power Format

[0350] In an example embodiment, the "Rx-power" term may refer to an 8-bit value of a predefined table of 256 possible received signal strength indication (RSSI) values ​​for tag targeting. In another example embodiment, the value may refer to 256 possible reference signal received power (RSRP) values ​​for tag targeting, in which case the receiver determines the RSRP by measuring the power of a specific portion of the tag report signal containing a reference signal sequence. Note that the tag report may contain some reference signal portion or "header" or "start symbol".

[0351] Security Part Data Structure

[0352] In an example embodiment, a "security part data" item may be a binary sequence of fixed length, e.g. 128 or 256 or 512 bits. The optimal length will also depend on the security properties of the security part data, e.g. based on which cryptographic function is used or which encryption key (length) is used. Note that a tag sighting contains security part data taken exactly from a sighted (i.e. received) tag report;

[0353] In the example simplified embodiment, it is assumed for simplicity reasons that tags may not sign / authenticate their reported tag sightings. However, it is worth noting that in another example embodiment, tags may sign / authenticate their reported tag sightings to improve location security / tamper resistance. Signing tag reports with embedded tag sightings allows the location service to collect and verify all tag sightings to verify that none of the tag sightings embedded in the tag reports have been added, removed, or altered, thereby improving the confidence of the derived location estimate and improving resilience to any such data modification attacks.

[0354] In an example simplified embodiment, the secure portion data may be the output of a cryptographic function F(.) on a particular data item, where the pipe | character represents the concatenation of data into a sequence. The secure portion data may be given by the following relationship:

[0355] Security Part Data =

[0356] {F(tag-temp-id|configuration data|timestamp|tx power|status bits)}(3)

[0357] Wherein F(.) can be a cryptographic hash function, or a hash-based message authentication code (HMAC) function, which is a message authentication code that uses a cryptographic key in combination with a hash function, or a block cipher-based message authentication cipher (CMAC) algorithm that can be used to provide authenticity and therefore integrity assurance of binary data. Function F(.) can additionally involve a truncation operation (TRUNC) or a Boolean operation (e.g., XOR) in any combination as shown in relation (5).

[0358] In relation (3), the "tag-temp-id" and "status bits" items are used by the tag when creating the secure portion of data for the tag report, but are not included as plain text data in the tag report message. This means that the location service must infer the values ​​of these items by looking them up in the secure database using hints such as those described below (for the case of "tag-temp-id") or by brute-forcing all bit combinations (for the case of "status bits").

[0359] In the example simplified embodiment, the "tag-temp-id" term acts as a symmetric "key" known only to the tag itself and the location service. That is why it needs to be long enough, e.g. at least 128 bits, to avoid brute force attacks to guess the temporary ID tag-temp-id.

[0360] In an example simplified embodiment, the "status bits" item may be 4 bits and include:

[0361] -Battery status indicator bit (1=normal, 0=low battery);

[0362] - Compact incremental encoding of sensor values ​​for sensors on tags (00 = no change; 01 = value increased by +1; 10 = value decreased by -1; 11 = sensor value returned to a preconfigured threshold), which enables location services to reconstruct actual sensor values ​​over time based on multiple tag reports from the same tag;

[0363] - gNB-coverage indicator bit (1 = in coverage, 0 = out of coverage).

[0364] Cryptographic function using HMAC and optional salt

[0365] In an example embodiment, the tag report and cryptographic function F(.) may be defined based on HMAC as follows:

[0366] tag report = {[configuration data,] [salt,] timestamp, tx power, F(.)}

[0367] F(.)=XOR(TRUNC(HMAC(tag-temp-id, [configuration data]|[salt]|timestamp|txpower), 40), status bits|0x00000000)(5)

[0368] in:

[0369] -HMAC(K, A) calculates the HMAC of A using the key K;

[0370] -TRUNC(A,B) returns the B bits of A, e.g., the B LSB of A;

[0371] -XOR(A, B) performs a bitwise exclusive OR of the bit strings A and B;

[0372] -A|B performs the concatenation of bit strings A and B;

[0373] -salt: An optional random "salt" parameter selected by the tag to be used as a password salt. It can also be thought of as a random number;

[0374] - Configuration data: optionally, shown here as covering embodiments that are included or not included;

[0375] – Status bits: 8 bits of status data determined by the tag.

[0376] An optional "salt" term / parameter can be used in this example embodiment to add more bit changes and optional additional randomness to the input of the function HMAC(.). For example, if the timestamp is chosen so that it does not change very frequently (perhaps the timestamp is updated only every minute), and if other inputs like the status bits, tx power and also the configuration data do not change during this time, such a situation may result in the same tag report that cannot be distinguished from a previous tag report, thereby bringing some risks: for example, an attacker may track two tag reports to the same node where they are not needed, or an attacker may "replay", i.e. retransmit a tag report at a later stage, thereby confusing it with the real tag report generated by the node. Therefore, salt may help to avoid these risks. Depending on the perceived threat and the resources available to the tag, the salt may take different forms. For example, in some embodiments, the salt may include a simple sequence counter that is incremented with each transmission. In other embodiments, the salt may include an arbitrary or cryptographically generated random number that is unique to each transmission. In both cases, the salt should be long enough to prevent the reuse of previous values ​​within a given time interval. If a salt parameter is used in the HMAC(.) calculation, the salt value must also be included in the tag report, and in each tag targeting data, the associated salt value (taken from the associated tag report being targeted) must be included so that the location service can ultimately use the correct salt value to calculate the cryptographic function. It should be noted that the above relationship (4) of the example embodiment shows the salt value being optionally included in the tag report, and, although not included therein for simplicity, in alternative example embodiments, the tag targeting data may also be included therein.

[0377] Upon receipt, the gNB / CN may communicate the tag targeting data to the location service. The location service may then obtain all tag-temp-ids known to be in the area of ​​interest or potentially in the area, calculate the HMAC as indicated, and take the 40 LSB bits of the output (i.e., TRUNC(x, 40)). Thus, by checking the 32 least significant bits (LSBs) (4 bytes) against the calculated value, the location service may know whether the reported tag-temp-id is OK. The server may then retrieve the status bits by XORing the security portion data (i.e., the F(.) component within the received tag targeting) with the calculated truncated HMAC(.) value and taking the 8 most significant bits (MSBs) (1 byte) of the result. Although the status bits are not integrity protected in this example embodiment, they have the advantage that the status bits are included in the tag report and are confidential, so that the location service does not need to infer the correct status bit value by brute force iteration of all possible status bit values, thereby saving computation time on the location service and allowing longer status bit sequences (e.g., 224, 128, or 96 bits instead of just 4 or 8 bits).

[0378] Assignment of tag-temp-id values

[0379] In an example embodiment, the core network (CN) may assign one or more temporary ids (i.e., "tag-temp-id" items or tag-temp-ids) to each tag in a secure manner, for example, via a location service. This is done using conventional 3GPP defined communications, such as a direct connection to the gNB (via UL / DL) or via a UE to network relayed UE connection (via SL). In addition, the tag-temp-id may be pre-configured on the tag to account for the possible situation where a tag (e.g., an OoC tag) cannot reach the CN during operation. These values ​​are stored in a secure storage element on the tag. Because the location service also knows the pre-configured tag-temp-id values ​​through a secure database lookup, the location service can try many values ​​of the tag-temp-id for those tags that it knows are near a particular gNB service area based on previous tag reports or connection log information from the gNB. When the location service finds a tag-temp-id value that matches the value used by the tag in the calculation of the security part data, the location service's own calculation of the hypothetical security part data using that tag-temp-id will match the security part data received in the tag targeting. This enables the location service to identify a specific tag among many (eg, millions) of other tags.

[0380] In an example embodiment, tag-temp-id values ​​may be assigned as cryptographically random values: for example, 128 bits in length or more. These tag-temp-ids (IDs) have a security role similar to temporary symmetric keys.

[0381] The tag may periodically (e.g. once a week) establish a full connectivity session to the RAN and CN and use this to retrieve updates to one or more tag-temp-id values ​​to be used from the location service, which are securely delivered to the tag and then stored within the tag's secure storage space. This can only be done when the tag is within the coverage of a gNB or a suitable UE-to-network relay UE that can provide connectivity services to the tag. It is important to note that this should be done as infrequently as possible to save energy on the tag.

[0382] A tag with multiple pre-stored tag-temp-ids (IDs) may cycle through these IDs based on a predefined policy (e.g., a timer that limits the time a single ID is used) when the tag is within the coverage of a gNB or relay UE, or based on the UTC time / SFN transmitted by such a node. Using pre-stored IDs may be useful for tags that are out of coverage for a long period of time or for their entire lifetime. A specific way of cycling through the tag-temp-ids may also be to calculate their values ​​based on a hash function F(timestamp, tag-id), where "tag-id" is the stable ID of the tag, and "timestamp" is the timestamp when the calculation is done. In this case, the tag reports the same "timestamp" value in its tag reporting structure, so that the location service can also derive the same tag-temp-id that has been used by the tag.

[0383] In an example embodiment, one or more tag-temp-ids may be pre-configured in the tag prior to field deployment (e.g., at the factory, by a vendor, etc.) so that the tag can function even when not within gNB coverage or relay coverage. In an alternative embodiment, pre-configuration may be performed in the field using dedicated tools, for example using short-range communications such as BLE, Wi-Fi or 5G NR SL D2D communications or NFC.

[0384] Temporary ID protected by a hash function with no state bits as part of the tag report

[0385] In an example embodiment, the temporary ID (i.e., the "tag-temp-id" term or simply tag-temp-id) may be part of a tag report, which may be given in a lightweight manner, e.g., without using standard encryption methods, without including state bits, and using a hash function H(.) according to the following relationship:

[0386] Tag report = {timestamp, tx power, H (tag-temp-id | timestamp | tx power)} (6)

[0387] Although the "tag-temp-id" item is included in the hash calculation, it may not be sent over the wireless communication channel. The location service must expend resources to try all possible combinations, for example, thousands to millions of known tag-temp-ids in a specific target area, which may be defined as a gNB / cell or an intersection area of ​​two or more gNB cells. Although not included in the above relationship (6) of the present example embodiment, it should be noted that in alternative example embodiments, the "configuration data" item may also be included therein. The "configuration data" item may be included only in a subset of the tag report messages sent in order to reduce bandwidth usage and power consumption of the tag.

[0388] Send encrypted status bits

[0389] In an example embodiment, if a larger amount of status bit data needs to be sent and the status bit data needs to still be integrity protected and confidential, the encrypted status bits can be included in the tag report of the above relationship (6). Optionally, the tx power and timestamp fields can also be encrypted, although this is not shown in the above relationship (6). Therefore, the tag report and security part data can be given by the following relationships respectively:

[0390] Tag report = {configuration data, timestamp, tx power, security part data} (7)

[0391] Security part data = {E(tagK, status bit), F(tag-temp-id|configuration data|timestamp|tx power|E(tagK, status bit))} (8)

[0392] As shown, the secure portion data may include an encrypted F(.) portion and status bits additionally encrypted in E(.), where E(tagK, status bits) is a cryptographic function that encrypts the “status bits” data using the tag’s (private) key “tagK”.

[0393] On its side, the location service may have the corresponding key or the same key to decrypt the status bits again according to the following relationship:

[0394] Status bits = D(tag K', encrypted data) (9)

[0395] Where D(tagK', encrypted data) is a decryption function that decrypts the "encrypted data" data using the key tagK'. The keys tagK and tagK' may be defined by the location service similarly to tag-temp-id, or may be derived therefrom. If tagK == tagK', symmetric key encryption is used. For asymmetric (i.e., public / private key-based) encryption and decryption, tagK may be the public key used for encryption and tagK' may be the private key used for decryption. The asymmetric option has the advantage that if an attacker manages to compromise a tag or number of tags, the attacker may not be able to obtain the tagK' required to decrypt (earlier and / or future) recorded messages containing E(tagK, status bits). In practice, the attacker should attack the location service infrastructure itself to obtain tagK', which may typically be better protected than low-cost embedded devices such as tags and therefore more difficult to successfully attack.

[0396] In an alternative example embodiment, the function F(.) may be computed on the truth values ​​of the state bits instead of the encrypted values ​​E(.), as given by the following relationship:

[0397] Security part data = {E(tagK, status bit), F(tag-temp-id|configuration data|timestamp|tx power|status bit)} (10)

[0398] The location service then has to perform many calculations of F(.) using not only the data available in the tag report, but also the decrypted status bits as input. In other words, for each hash calculation F(.), the location service must first perform a decryption function D(.) using the corresponding stored key, which increases the computational load. However, this may have the advantage that it may be more difficult for an attacker to launch a brute force attack by trying many tag-temp-id values. In combination with the above asymmetric option, another advantage may be that an attacker who obtains the public key tagK stored inside the tag may still not execute the function D(.) to obtain the status bits, making it more difficult for the attacker to use a brute force method to decode the record tag report sent by the tag (e.g., by iterating over many generated potential tag-temp-ids) because the attacker lacks the input value "status-bits" required to perform such an operation / calculation.

[0399] Send tag-temp-id hint or summary as part of tag report

[0400] In an example embodiment, a hint or summary of the tag-temp-id may be transmitted within a tag report to help the location service speed up searches among 1,000 to 1,000,000 or more tag-temp-ids. The summary length may be configurable so that the system can scale. This configuration may be part of the "configuration data" of the selected profile or may be part of a separate "configuration data" field indicating the summary length in bits. For example, a 2-bit summary has reduced the hash calculations required by the location service by an average of 75% while not disclosing much information about the true identity of the sending tag.

[0401] The hint can be calculated in various ways, for example, by taking every N bits of the tag-temp-id or a single parity bit calculated over the tag-temp-id.

[0402] In an alternative embodiment, the tag may be provided (e.g., by the network or access device or UE or intermediate node) in a downlink message (e.g., a wake-up message or a tag configuration message) and a hint is provided that the tag needs to be used in a tag report. In one variation, the hint mask contained within the downlink message may be combined with elements of the tag identity to create a complete hint for use in a tag report. For example, the hint provided may be XORed with the last few bits of the tag identifier or some other predefined bit selection. This allows the network to effectively change the hint for a group of tags in a single wake-up message. Hint conflicts may be resolved by the network, so they do not need to be unique.

[0403] Send information about the next tag wakeup time in tag reports

[0404] In an example embodiment, a tag may send information in its tag report that identifies or helps identify the next time slot that the tag will wake up again to perform a new tag report or listen for a tag report. Receiving this information may occur in several situations:

[0405] - If a neighbor tag receives this information about the next wake-up time for transmission, it can adapt its own wake-up schedule to receive at that time;

[0406] - if a neighbor tag receives this information about the next wake-up time for reception, it may adapt its own wake-up schedule to send an additional tag report at that time, so that the tag may receive the additional tag report during its next wake-up time;

[0407] - If the gNB receives this information about the next wake-up time for reception, it may schedule the transmission of new tag configuration data or a tag “paging” request or other message indicating DL data for the tag at the next wake-up time:

[0408] If the tag is later detected by a different gNB, indicating that it has moved to a different cell coverage area during its sleep cycle, then the gNB with the scheduled transmissions may remove the scheduled transmissions for that particular tag;

[0409] - If the gNB receives this information about the next wake-up time for transmission, the gNB can schedule its cellular communication traffic UL / DL such that enough resources are available in the next wake-up slot to allow the tag to make its transmission without too much interference caused by this other UL / DL traffic:

[0410] If a tag is detected by a different gNB, indicating that it has moved to a different cell coverage area during its sleep cycle, the current gNB may remove the scheduled reception for that particular tag. Instead, the current gNB may use the slot for other purposes, or reserve the slot for listening to other (potential) tags that may use the slot in the future;

[0411] If a SL-UE receives this information about the next wake-up time for a transmission, it may configure itself to listen for any transmissions from the tag at this indicated wake-up time. If it receives such a transmission, it may report it to the location service or alternatively to its gNB.

[0412] This information may include:

[0413] - an indicator of a time increment or future time slot, e.g. a timestamp / SFN number / UTC time value or a part / fraction thereof;

[0414] -Energy / power collection state information from which the receiver (e.g., gNB) can accurately or approximately infer the tag’s next wake-up time.

[0415] gNB private configuration of Rx time window for tags

[0416] In an example embodiment, the gNB may privately configure the time window of a tag to modify the default calculated receive time window, extend or replace it. This may be done using private (security protected) unicast communication with the tag. The gNB may do this for tag T so that tag T can better receive tag reports from neighbors of tag T that may send their tag reports "early" or "late" in the time window. Or, neighbors of tag T that are operating under a different gNB / cell and may therefore operate using different configuration information (e.g., another time window).

[0417] gNB private configuration of tag Tx time window

[0418] In an example embodiment, the gNB may privately configure the moment to send tag reports for a specific tag T using, for example, private unicast communication to tag T. The purpose of doing this may be to propagate tag targeting faster through the network. Figure 6 Schematically illustrates an example private configuration of the Tx time window of an in-coverage tag T 601 (small hollow circle) by a gNB 621 (large circle) according to one embodiment of the present invention. As depicted, there are OoC tags 611, 612, 613 (small solid circles) that report at corresponding random times t=1, 2, 3 (Tx@t=1, Tx@t=2, Tx@t=3). The gNB 621 then configures (cfg) the in-coverage tag T 601 with a Tx time of T=4 to ensure that when the in-coverage tag T 601 sends (one-way arrow) its report message to the gNB 621, the report message includes all tag sightings collected from other tags 611, 612, 613 at times 1, 2, 3. In this way, the location service (not shown) can obtain the latest information and the delay between the time when the tag report is sent and the time when the location service generates a position estimate is substantially reduced.

[0419] It is worth noting that, ideally, the rightmost tag 613 would be reported at t=0 so that its closest tag sighting could also be included by tag 612 reported at t=1 (Tx@t=1). Unfortunately, this is not possible, since in this example embodiment, the gNB 621 has no access to the OoC tags 611, 612, 613. However, this can be solved in different ways, for example, by configuring other tags via a relay UE, with the in-coverage tag T even being able to act as a simple relay. Other solutions can be proposed, in particular the solution proposed below.

[0420] Automatically configures the Tx time reported by tags to minimize latency in tag targeting

[0421] Reference examples Figure 6 , by observing the connection status of the tag itself and its neighbors, it is possible to automatically configure the tag's Tx time. In particular:

[0422] - The left tag 601 (depicted as corresponding to Tx@t=4) determines that it is within the coverage of gNB 621: it can then schedule itself later in the time window;

[0423] - The two tags 611, 612 in the middle (depicted as corresponding to Tx@t=1 and Tx@t=3) determine that they are OoC to gNB 621, but they have neighbor 601 (depicted as corresponding to Tx@t=4) in coverage of gNB 621: they can then schedule themselves in the middle of the time window;

[0424] - The right tag 613 (depicted as corresponding to Tx@t=2) determines that it sees no neighbor tags that are within coverage of gNB 621 and that it is out of coverage of the gNB: it can then schedule itself early in the time window.

[0425] Tags can infer this in-coverage / out-of-coverage status by including the relevant status bits in the public data portion of the tag report, for example:

[0426] - in gNB coverage bit: set to “1” only by tag if in gNB coverage;

[0427] - Neighbor in Coverage bit: Set to “1” only if at least one neighbor tag reported “In gNB Coverage bit = 1” within the last time window.

[0428] The result of this is that the tag report message from the distant (i.e., rightmost) tag (e.g., 613) propagates to the gNB (e.g., 621) faster, thereby reducing latency and resulting in an up-to-date position estimate for the tag (e.g., 613). For example, if the tag reports once an hour, then when the location service receives the rightmost tag (e.g., 613), the tag's tag sighting may always be 1 hour ago or 2 hours ago, depending on the randomly selected tag transmission time and assuming that in this example case, the tag will generally stay in the same randomly selected time slot within a time window. In fact, in the example of the rightmost tag 613, depending on the scheduling time and 3-hop propagation of the tag report of tag 613, it may be 0, 1, 2, or 3 hours ago. By applying this example embodiment, when the location service receives the tag sighting, the tag sighting may always be 0 hours (perhaps a few seconds) ago.

[0429] Include hop limits or hop counts in tag reports

[0430] In an example embodiment, a tag report message may include a hop limit or hop count value in the common data portion. This enables a tag to, for example, decide not to forward a tag report to other tags / UEs in the form of tag targeting, for example, if the hop count value counts up until a preconfigured threshold is reached, or if the hop limit value counts down until 0 is reached. This has the advantage of improving efficiency, as a particular tag report is not resent for a long time or multiple times. Another advantage is that if the hop count / hop limit information is included in the tag targeting, it may enable a location service to better estimate the location of the tag.

[0431] Include "needs to forward" bit in tag reports

[0432] In an alternative or additional example embodiment with respect to the hop count / hop count functionality described above, a tag report may include a "needs forwarding" bit. If set (1), the tag report may be forwarded to other tags / UEs as tag targeting. If not set (0), the tag should not include it in tag targeting and only the gNB will collect and report the tag report as tag targeting for location services. A hop limit value equivalent to this bit, such as 0 or 1 (depending on the protocol convention used), may be used as an indicator of "do not forward" with hop limit = 0 (i.e., the tag report will not be forwarded) or an indicator of "needs forwarding" with hop limit = 1 (i.e., the tag report may be forwarded one more time).

[0433] Priority values ​​included in tag reports

[0434] In an example embodiment, a tag report may include a priority value (e.g., 2 bits) in the common data portion. This helps tags sending tag sightings prioritize among tag sightings to include in their tag reports. For example, a tag may include as many tag sightings as possible within a particular tag report target size (in bytes); starting with including the tag sighting with the highest priority, then including tag sightings with lower priorities, and so on, until the target tag report size is reached (or including another tag sighting would exceed the target tag report size), or until there are no more tag sightings to include.

[0435] Select the tag you want to report on

[0436] In an example embodiment, a tag may report or send some or all of its tag sightings to nearby nodes (e.g., gNBs or other tags) as part of a tag report. If there are too many tag sightings to report within a limited time window or on a limited energy budget on the tag, a strategy may be used to select the tag sightings to report. One specific choice in this embodiment is to not report tag sighting events that have been reported at least K times by other nearby tags. Here K is a configurable or predefined parameter or threshold. If at least K tag sighting reports have been seen from neighboring tags, the tag will suppress new reports of the tag sighting. Another strategy may be to suppress reports on old tag sightings in favor of new sightings that still need to be reported. Older tag sightings can be determined based on the timestamp value in the corresponding tag report and / or the local time of the tag that records the tag sighting. The latter can typically be equal to the time when the corresponding tag report was received. Reports not selected / sent based on the selection strategy may be discarded or transmitted later.

[0437] Another embodiment for selection is by using priority values ​​as described above.This selection by priority can be combined with the above-described tag targeting selection based on tag targeting age, or with other criteria for selecting the most relevant tag targeting.

[0438] Send additional tag targeting information directly to the gNB

[0439] In an example embodiment, in-coverage tags may periodically connect to the gNB and send the tag sightings collected so far via a regular (e.g., 5G NR) Uu uplink connection. Although this periodic connection may be performed less frequently than necessary to reduce tag energy consumption, it may be useful in the following example scenarios:

[0440] - Many tag targeting events that the tag has collected are not suitable for regular tag reporting (e.g., because of limited capacity to include tag targeting events);

[0441] - The tag needs to connect to the gNB anyway to send sensor data, check for firmware update availability, check for configuration updates or update its firmware, etc.

[0442] - Tag targeting information has been collected for tag reports that are no longer forwarded (e.g. because they are marked as "do not forward" or marked with hop limit = 0), but can still be reported to the gNB.

[0443] Thus, when connected to the gNB, the tag may report all tag targeting events still available in its internal storage, even those that have been previously included in a tag report. Alternatively, in order to reduce the time and / or energy used for transmission, it may also selectively include tag reports (e.g., reporting in a tag report only those tag targetings that have not yet been sent, or reporting only the highest priority tag targetings, etc., optionally using a method similar to one of the selection methods described in the present invention to select the tag targetings in the tag report). Depending on the implementation of the tag, the tag may delete some or all tags after reporting these tags to the gNB over a dedicated UL connection.

[0444] Tag targeting reported within the protection tag report

[0445] In an example embodiment, a tag may protect its reported tag targeting in order to avoid false reporting or tampering associated with a tag report that includes tag targeting information. Such a "malicious" report or tampering may be initiated by another type of gNB, tag, or on-path attacker (e.g., a compromised device in the UE or RAN or CN). An example of tampering might be that node N1 receives a genuine tag report from tag T1 and adds that tag report as a tag targeting for tag T2, thereby falsely implying that T2, rather than N1, has received the tag report from T1. However, if it were possible for T1 and T2 to "digitally sign" the tag targeting, then such an attack would be more difficult to conduct. Therefore, an example solution may include sending a tag report with a payload embedded therein according to the following relationship:

[0446] Tag report = {timestamp, tx power, payload, H(tag-temp-id | timestamp | tx power | payload)} (11)

[0447] Wherein the "payload" portion may be one or more concatenated tag targets. The hash function H(.) verifies the tag target of the tag so that it can become tamper-proof when the tag report itself is in turn forwarded in an embedded form in the tag report. Although not included in the above relationship (11) of the present example embodiment, it should be noted that in alternative example embodiments, the "configuration data" item may also be included therein.

[0448] Digest (abstract / hash) form of tag targeting

[0449] The size of the "payload" portion described above may be quite long when including a tag targeting with complete "security portion data", and may be even longer when using a tag targeting with complete "tag report" data. In an example embodiment, instead of a complete tag targeting, a tag may also report a summary / digest tag targeting, which is a tag targeting that is encoded as a shorter version of the tag targeting than the complete tag targeting. For example, it may contain only a summary (shorter) version of the security portion data, while the other data elements of the tag targeting remain unchanged. Alternatively, it may include a summary (shorter) version of all data elements of the tag targeting. It is worth noting that the summary of the security portion data may effectively be considered equivalent to the summary of the tag report.

[0450] This allows a tag to send out a tag report containing more tag targetings packed into the same space, provided that at least one tag targeting is included in its summarized form. However, it is worth noting that if every tag reports a summarized tag targeting instead of the full tag targeting for each tag targeting, this will not work, as the location service will not be able to reconstruct the original tag targeting data associated with the summarized form. Therefore, at least one complete (i.e., non-summary) tag targeting must be sent to the location service (without getting lost on the way). If such a complete version of a tag targeting is received at the location service, other tag targetings that include exactly the same data (in whole or in part, e.g., only the security portion data may match exactly while other fields may differ) may refer to summarized tag targetings instead of full tag targetings, and the location service may still correctly use these summarized tag targetings as if they were full tag targetings.

[0451] It is worth noting that using a summary rather than a full version necessarily omits some information. Therefore, there may be a risk that the summary may no longer be uniquely associated with a tag sighting with 100% certainty. This is similar to the case when representing information with a hash: there may always be a probability of a hash value collision, no matter how small. To reduce this risk of collision, the summary can be chosen to be a sufficiently long number of bits (e.g., a hash) so that the probability of a collision with other tag sighting events generated in the same cell / area within a specific, identical time period (e.g., a day or an hour) is very small (e.g., <0.0001%). Because the summary (e.g., hash value) does not have to be unique across a wider area (e.g., a country, continent, or around the world) or locally unique over longer time scales (e.g., a day, a week, or longer), the summary length can still be kept relatively small to achieve the benefits of a reduced size of the tag sighting and / or the ability to include more tag sightings in a tag report.

[0452] In order to implement the feature that the location service receives at least one complete tag sighting in addition to a digest of the same tag sighting, so that the digest can be referred to the complete tag sighting with high probability, specific rules / policies may be needed to send the digest instead of the complete version of the tag sighting. Therefore, possible rules / policies to achieve this goal may include at least one of the following:

[0453] - A tag may only report a summary of the security part data within a tag sighting if the tag has seen the same security part data already included in the tag sighting of other in-coverage (peer) tags at least N times, where N is a configurable or predefined value (e.g., N=3);

[0454] - The timestamp of the tag sighting can be used as a summary, or as part of a summary, as a unique ID for the tag sighting within a local area. The local area can include the tag area reporting the above tag sighting and its immediate neighboring tag areas;

[0455] - the first N bytes of the security part data and / or a short hash of the security part data (e.g. 24 bits or 32 bits) may be used as a digest;

[0456] - An out-of-coverage tag may only start using a digest of a particular security portion data in its tag targeting if it has seen at least M other neighbor tags within the coverage of the gNB use a digested form of that security portion data in their reported tag targeting, where M is a configurable or predefined value (e.g., M=1). Meanwhile, an in-coverage tag may start using a digest of a particular security portion data upon obtaining some form of confirmation that the gNB has received the full version of the security portion data embedded in the tag targeting data element. Such confirmation may be achieved in various ways, for example, by reporting the tag targeting to the gNB (which may be by broadcasting in the usual manner in a tag report, or by using a dedicated unicast connection to the gNB), and obtaining a confirmation message from the gNB regarding receipt of the tag targeting. The confirmation message from the gNB may be in the same form as the tag report sent by the tag, but now sent by the gNB in ​​the next time window, with the gNB including a digest of the particular security portion data in the tag targeting data structure as an indicator of knowledge of that particular security portion data. Alternatively, the confirmation message may have some other form than the defined tag reporting structure, such as a simple confirmation message acknowledging receipt of a previous transmission by a tag of a tag targeting or tag targeting set.

[0457] In an example specific embodiment, a location service that sees a digest value reported in a tag sighting, but cannot find the corresponding complete security part data, may issue a request to one or more gNBs to perform a "paging" operation to request that any tags that still hold a complete tag sighting for this security part data digest report the tag sighting in full to their gNB. Such a "paging" operation may be accomplished by creating a temporary change in the configuration data, for example, by extending the length of the "configuration data" field with an additional bit string that encodes the identity of the requested security part data digest. Such encoding may consist of, for example, the complete digest form of the security part data, or may be a shorter form, such as a digest form of the digest.

[0458] Configuration data that includes predefined target parameters for tag targeting to be included in tag reports

[0459] In an example embodiment, the "configuration data" item may include a setting or predefined number indicating the target number of tag sightings that are preferably or maximally included or embedded in the tag report. This enables the RAN to find a trade-off between tag efficiency (i.e., smaller messages are sent, thereby saving power on the tag) and the quality of the available information (i.e., more tag sightings are available to reconstruct the tag position with higher accuracy and confidence). For example, the predefined target number of tag sightings may be, for example, a 4-bit value that directly encodes the target number 0-15 so that the tag sighting number is preferably included in the tag report message. Alternatively, it may be a 3-bit value that indicates an index 0-7 of a predefined lookup table, where the table value determines the predefined target number. Optionally, if more high priority tag sightings are made and the predefined target number value is exceeded, the tag may still decide to report these high priority sightings.

[0460] In another example embodiment, a "Configuration Data" item may alternatively or additionally include a setting or predefined number indicating a corresponding or overall target size (e.g., in bytes) that the tag is aiming for to be preferably or maximally included or embedded in the tag report.

[0461] In another example embodiment, the "Configuration Data" item may alternatively or additionally include a set or predefined number indicating a target number of summary and / or complete tags to preferably or maximally include or embed in the tag report.

[0462] Handling gNB cell boundaries

[0463] One problem may be related to time synchronization in the presence of several nearby cells. Figure 7 An example of an OoC situation in a location system with two cells is schematically shown, where in-coverage tags 701, 702, 703, 704, 705 and out-of-coverage tags 711, 712, 713 represented by small circles and distributed in the two cells are to be located. Figure 1Similarly, tags 701, 702, 703, 704, 705 represented by small hollow circles can transmit RF signals that can be received at the corresponding nearest anchor nodes 721, 722, 723 represented by large circles and distributed in two cells. Tags 711, 712, 713 represented by small solid circles are OoC and cannot directly transmit to any anchor node 721, 722, 723, but can transmit to nearby tags (e.g., 701, 702, 704, 705) and can also receive from nearby tags, as shown by the double-headed 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 nearby cell (e.g., cell 2) that another gNB uses to determine different time window information. In this case, the tags 704, 713 located between the two cells 1, 2 (i.e., tags near the dotted line) will have a problem, that is, if they are synchronized with the time schedule of the tags 705 / anchor node 723 of one part (e.g., those in "cell 2"), they will not be able to communicate with the tags 702, 703, 711, 712 in the range of the other part (e.g., tags in "cell 1"), and vice versa. The dotted arrow with the symbol "?" shows that the tags of cell 1 cannot communicate with the tags of cell 2 within the shared time window. Therefore, if the two cells 1, 2 are configured with different time windows, the transmission and / or reception windows for these nearby in-range tags will "miss" each other in time, and if the two cells are configured with different frequency resources for the tags, they may "miss" each other in frequency.

[0464] In an example embodiment, at the border area of ​​different (e.g., N) gNBs / cells, there may be different RAN configurations for the tags present for each involved gNB / cell. In particular, the time windows may be defined differently so that tags in the border area cannot receive tag reports of each other's tags propagated in the cell coverage area, such as Figure 7 In order to improve the accuracy and confidence of the location estimates of all the tags involved, it would be beneficial if those tags on the border area are still able to successfully send their tag reports to all neighboring tags despite the differences in configuration. In fact, the more neighbor tags there are, the better the location estimate is likely to be and the stronger the evidence that the tag is indeed at a specific location at a specific time, effectively improving the coverage area in which the system operates.

[0465] Certain embodiments may allow a tag to be configured with N configuration data sets, typically N=2 or N=3. For example, for N=2, the tag may apply both configurations and monitor two time windows when both configurations are active. In one example, the tag may determine the two configurations by observing different nodes in the area broadcasting different configurations. These different nodes may be, for example, gNBs, relay UEs, NR SL SyncRef UEs, or peer tags. If there are too many conflicting configuration data sets, any configuration data sent by the gNB may take precedence over configuration data sent by any other node.

[0466] Another specific embodiment may include enabling one individual gNB to send configuration data of other gNBs / cells in the vicinity in order to allow tags located near a cell border to use it. The tag may then detect that it is near a cell border by trying a second time window of configuration data for a period of time and by counting the number of tag sightings in this additional (second) time window. If this number is above a predefined threshold T, the tag may know that it is near a cell border and will also continue to monitor an additional time window. Otherwise, the tag may stop monitoring this additional time window or monitor it sporadically. Sporadic monitoring reduces the energy consumption of the tag compared to continuous monitoring of the additional time window and is therefore beneficial. Note that due to tag displacement / movement, the tag may move towards the cell border at a later point in time or even enter the coverage area of ​​a second gNB / cell. Then, it may also make sense to apply the additional (second) configuration data. To this end, the tag may use available sensor data (e.g. from a motion sensor) as a decision criterion for deciding whether to monitor the additional time window the next time this time window occurs.

[0467] Another specific embodiment may include configuring adjacent cells with the same time window but with different frequency channel settings, thereby allowing all tags even at cell borders to use the same time window. However, this makes the overall system less flexible in terms of adjusting the time window according to the number of currently active tags. Such second configuration data, which differ only in frequency, can be effectively encoded using only one additional (second) field "frequency / channel", for example, included in or appended to the "configuration data" item of the tag report.

[0468] Another specific embodiment may comprise including in the configuration data a "time shift" parameter which, when non-zero, may indicate a second configuration valid for the tag to be used by applying a time shift of the time window. This has the advantage that the second configuration data set may be encoded very efficiently. It may therefore be considered a specific sub-case of the N=2 case of the different configurations described above. Likewise, for N=3, there may be a second time shift parameter. Furthermore, a variable length time shift array of length L=0, ..., K may be encoded, allowing encoding of the number of configuration data sets (1, ..., (K+1), respectively) that differ only in the relative positioning of the time window. In an example embodiment, two neighboring gNBs may arrange to coordinate to align their configuration data such that a simple "time offset" or "frequency change" may be efficiently encoded in the "configuration data" of two cells served by (or in the coverage area of) these gNBs.

[0469] In the example case where a single configuration data implements N (=2) different time windows, these time windows reuse time windows of the same duration and the same frequency / channel:

[0470] - Frequency / channel selection: 8 bits;

[0471] -Time window position selection: 8 bits;

[0472] -Time window duration selection: 4 bits;

[0473] -Time window shift selection: 4 bits:

[0474] A value of 0 indicates "no time shift", i.e. no second / additional configuration data set is active.

[0475] RAN adjusts time window configuration based on label density

[0476] In example embodiments, during its operation, the RAN may adjust the "config-data" settings to accommodate changes required, for example, due to changes in tag density in the geographic area of ​​interest. For example, if the RAN gNB observes that the "target duration" of the time window defined in Table II above associated with the option settings of the time scheduling parameters of the "config-data" structure consistently exceeds a certain number N of tags within the coverage area of ​​the gNB, the gNB may select a new time window configuration that allows for longer time windows. Such configuration changes may also be coordinated by multiple gNBs of the RAN. Conversely, in cases where tag activity is low in the geographic area of ​​interest, the gNBs of the RAN may reduce the "target duration" of the time window. The resulting configuration data changes that the observing RAN gNB may then record and save for reporting to the location service as well, which may then use these configuration data values ​​to validate the tag reports. In these examples, while the gNB or multiple gNBs or RAN management functions may determine the new configuration ("config-data"), this may also be achieved through a negotiation process between the gNB / RAN and the location service, or it may be a decision made by the location service using only status reports and / or operational constraint data from the gNB / RAN as input data for making this decision.

[0477] Location service to identify real tag ID from secure part data

[0478] In an example embodiment, a location service may potentially receive many tag targetings that include security portion data. These security portion data fields are embedded in tag targetings generated and / or reported by nodes in the cellular network that report these tag targetings to the location service (directly or indirectly), such as generated by a gNB, a SL UE, a tag (e.g., an in-coverage tag reported to the location service via a UL unicast of a gNB), or other UE capable of receiving tag reports. It is noteworthy that according to the present invention, a tag targeting may in turn include (e.g., as an embedded data field) or refer to (e.g., via a digest, hash, timestamp, etc.) one or more other tag targetings. In a specific implementation, a tag targeting may even include a complete tag report message, which may embed one or more further tag targetings including a security portion data field. The result of this is that for all known tag-temp-ids (which are suspected to be in or were previously in the geographic area of ​​interest), the location service can identify the real tag ID that originally created the data for a given security part data by calculating (or operating) the cryptographic function F(.) of relationship (3) until a matching tag can be found so that the calculated function F(..) data matches the security part data. For the status bits, the location service must also try (brute force) all possible combinations that may be combined with the above loop and cover all known tag-temp-ids. As an optimization, the location service can first try the combination of the last reported status bits, assuming that there has been no change in the meantime. If the status bits do not change regularly, this helps reduce the amount of calculations that the location service needs to perform on average.

[0479] The "tag-temp-id" and "state bits" terms in the function F(.) of relation (3) are included in the cryptographic calculations, but they are not sent over the wireless communication channel. Therefore, the location service must expend resources to try all possible combinations, e.g., thousands to millions of known tag-temp-ids in a specific target area (e.g., which can be defined as a gNB / cell coverage area or an intersection area of ​​two or more gNB cells). Due to advances in computing technology (e.g., clouds designed for efficient hashing / encryption batch operations for blockchains), location services can perform such calculations efficiently. Note that there may be a large number of candidate tag-temp-ids. Because in some cases, location updates may be relatively slow (e.g., tens of minutes or hours) to save energy on the tag, the additional computational delay of a few seconds or minutes for the location service is still acceptable.

[0480] It should be noted that in the example specific case where a location service cannot decode certain tag reports, it can send these tag reports to other location services to use, for example, a location service from another operator covering the same geographic area, or a location service in a neighboring area. This has the benefit of potentially improving the location accuracy and confidence of the location estimate used by the receiving location server.

[0481] Using 5G-NR ProSe Open Discovery Message

[0482] In an example embodiment using 5G-NR ProSe open discovery messages per 3GPP TS24.554 (Release 17), the tag may then send a discovery message in the role of announcing the UE. The message is not encrypted at the ProSe layer, but may be integrity protected using a message integrity check (MIC). The MIC may be calculated based on a key derivation function (KDF) using the configured Discovery User Integrity Key (DUIK) as input.

[0483] The DUIK can be configured on each tag similarly to the tag-temp-id. Optionally, the tag-temp-id can be derived from the DUIK, or the DUIK can even be chosen to be equal to the tag-temp-id. Optionally, a monitoring UE receiving a ProSe discovery "announcement" message can verify the message by having the message verified by the core network ProSe related services. This can work by reporting the reception of the discovery message per 3GPP TS24.554 (Release 17). The tag can optionally act as a full monitoring UE as specified by 3GPP (e.g., 3GPP TS24.554 (Release 17)), or the tag can implement a subset thereof. Another (sidelink) UE that is not a tag can also act as a monitoring UE.

[0484] The MIC of the discovery message can be considered as part of the tag report message sent by the tag. The MIC can then be included in the tag sighting, allowing the relevant network service (e.g., ProSE function or location service) to verify the MIC reported by each tag it handles. Note that the network service can access the configured DUIK for each tag (e.g., locally, or through interaction with the DDNMF, or other), and can therefore verify the MIC.

[0485] Please refer to 3GPP TS 33.503v15.0.0 Figure 6.1.3.3.1-1 "Integrity protection of the transmitted code" discovery message flow is used to describe the above example embodiment. For a tag announcing UE, it is assumed that steps 1-4 are only completed once (while in network coverage), rather than every time. For monitoring UEs that are interested in having tag reports verified by the network, steps 11-15 can be used to achieve this. The DDNMF is involved in allocating keys, and interaction between the DDNMF and the LMF may be required in order to assign the correct keys for the tags to be used.

[0486] Tag Paging

[0487] In an example embodiment, an entity may determine that it does not have the most recent location data for a particular tag of interest, or that it has data but that it is not accurate enough. The entity may be the location service itself or a client of a location service. This embodiment enables sending a specific request or "paging message" to obtain closer and / or more accurate location information for a particular tag of interest. This may be accomplished by triggering more tag targeting or more tag reporting for the tag. This may be a conventional cellular paging message (e.g., as specified in 3GPP TS 38.300) adjusted / extended for this purpose, or may be a paging message for low-power tag operation, such as a bump signal for backscatter communications, which may incorporate / modulate some paging-related information fields into the signal, or a wake-up signal as described in other embodiments.

[0488] This embodiment begins with the location service determining (e.g., by receiving from a client, or by its own initiative, or driven, for example, by a service level agreement (SLA) with a tag customer, etc.) the current active tag-temp-id of the tag of interest. This tag-temp-id can then be used as an input to a cryptographic one-way function F(.) along with at least one other input known to both the location service and the tag. Several examples are shown below:

[0489] –Paging-id=F(tag-temp-id, other-data);

[0490] –Paging-id=F(tag-temp-id, other-data, salt);

[0491] –Paging-id=F(tag-temp-id, salt).

[0492] If the “salt” item is used, it may be sent along with the Paging-id. However, location services never send a tag-temp-id. Based on predictions of tag mobility, this paging-id may be sent to one or more gNBs in the area where the tag was last seen and / or in areas where the tag may have moved during this period. The gNBs may now include this paging-id information in the additional tag reports they send for all tags in their service area to receive. Alternatively, the gNB may send an additional message of another type / format different from the tag report, where the additional message may be similar to the tag report received by the tag during the time window.

[0493] Any tag receiving a paging-id tag report may then check if it is addressed to itself by computing the function F(.). It is noteworthy that the paging-id may be pre-computed without the use of a "salt" term. If a tag is paged, then it may send at least one new tag report. Optionally, this new tag report may include a "paged" bit set to 1 in the common data portion, or a priority field set to the value "high", so that other tags doing tag targeting may know to include this tag report with a higher priority when reporting tag targeting to the gNB and / or to peer tags in their own tag reports.

[0494] Optionally, tags may implement security measures to avoid battery drain attacks caused by an attacker sending many meaningless paging requests to the network, thereby performing a large amount of additional processing operations on all tags receiving such paging requests. For example, the number of paging requests may be limited to a maximum of N per time unit.

[0495] Optionally, the paging message may include a request for specific information, such as a flag indicating that the tag is requested to send updated location information, or a flag indicating that the tag is requested to resend its location information, or a flag indicating that the tag is requested to send information for a specific sensor. Optionally, the paging message may include one or more thresholds for the requested information, which may indicate minimum and / or maximum differences since the tag device last sent the requested information (e.g., a minimum distance indicating that if the device is still within a minimum distance of the location previously sent by the tag, it does not need to send its location information to the network, and if it is outside a minimum distance outside of the location previously sent by the tag, it does need to send its location information to the network).

[0496] Optionally, the paging message may include a time value indicating the time value when the network last updated / received the location or other data (e.g., sensor data) of the tag and / or the original timestamp of the location / other data provided in the tag report message. The tag may use this information to decide whether to send its location or other data (e.g., sensor data) to the network, for example, after determining whether the location or other data (e.g., sensor data) has changed or changed sufficiently (e.g., exceeds a certain minimum value) since the network last received the location or other data from the tag.

[0497] Optionally, the paging message may include the last received location information or other data (e.g., sensor data) received from the tag. The tag may use this information to decide whether to send its location or other data (e.g., sensor data) to the network, for example, after determining whether the location or other data (e.g., sensor data) has changed or changed sufficiently (e.g., exceeds a certain minimum value) since the network last received the location or other data from the tag.

[0498] Tag paging using System Information Block (SIB)

[0499] In an alternative example embodiment of the above embodiment of tag paging, tag paging may utilize a SIB, such as specified in 3GPP TS 38.331, extended for this purpose, such as by adding information elements or defining a new SIB type with the same / similar content as the above paging message. As another alternative embodiment, a Wi-Fi beacon or probe response is adapted / extended for this purpose by adding information elements with the same / similar content as the above paging message.

[0500] Tag Paging using ProSe Model B Discovery Messages

[0501] In an alternative example embodiment of the above embodiment of tag paging, tag paging can utilize restricted (non-open) ProSe Model B discovery messages. The discovery entity can then send a protected discovery request message with specific parameters, and only if the request can be correctly decrypted and the tag ID matches the "paged" / requested tag identity, i.e., the same "tag-temp-id", the matching tag can respond to the discovery request message with a discovery response message.

[0502] Indirect tab paging or the concept of "Have you seen this tab?"

[0503] In an example embodiment, rather than paging only tags of interest as described above, all tags may now be requested to report any information they may still have stored about a particular tag, but which they have not yet reported due to, for example, a process for selecting which tag targets to include in their tag reports, that particular tag was excluded from some or all tag reports.

[0504] To do this, the location service may compose a paging request that includes an identifier of the most recent tag report or tag sighting that the location service would like to learn more about. For example, the identifier of interest may be one of the following:

[0505] - the first N bits reported by the tag;

[0506] - The first N bits of the security part data;

[0507] - the (truncated) hash of the tag report;

[0508] - the (truncated) hash of the tag target;

[0509] - Summary of tag targeting;

[0510] - a (truncated) hash of the security part data;

[0511] - Timestamp in the public data section of the tag report;

[0512] - combinations thereof.

[0513] Preferably, the identifier is as short as possible. In an example sub-embodiment, a variable length identifier may be used: the longer the variable length identifier, the higher the probability of uniquely matching only expected tag reports, for example using a Bloom filter data structure.

[0514] Similar to the tag paging embodiment described above, the location service may send a request to the target gNBs, which may then distribute the paging request to tags in their service area, or, for example, broadcast a system information block, which may be received directly and / or indirectly by the tag (e.g., after the tag forwards the corresponding received system information block to one or more other tags (e.g., similar to forwarding system information blocks in ProSe / sidelink relays and / or transparently forwarding system information blocks)). Now, any tag that receives this request and still has a matching tag report and associated tag targeting metadata buffered (which may be recent or even slightly earlier) may prioritize this tag report for inclusion as a tag targeting in the next tag report sent to the gNB (or generally sent as a broadcast in the form of a tag report to the gNB and other tags). As a result, the gNB may receive more tag targeting for this particular tag report, and the location service may therefore better estimate the location and / or past location of the tag of interest. In addition, when a tag of interest sees a paging request, or an old tag report of its own is sent by another tag, or a combination of the above, it can react by immediately sending a newer tag report, for example, which can have a higher priority than the normally assigned priority (as described above, the tag report can include a priority value (e.g., 2 bits) in the public data portion). This allows the location service to then obtain the latest location data for the tag of interest in addition to the old tag report it requested, so as to better reconstruct the tag's current location and the potential movement trajectory that led to that location.

[0515] It is worth noting that since tags do not use any identifying information in their tag reports, other tags cannot establish the true identity of a tag that has sent a tag report, so the concept of "have you seen this tag" may necessarily be achieved by not requesting a specific tag ID (such as "tag-temp-id"), but rather requesting other identifiable information such as a tag report or tag sighting, in this case, referenced by its identifier.

[0516] In additional example sub-embodiments, the location service may request a specific timestamp value or timestamp range in its paging request in order to collect data about specific tag reports that were missing or not collected enough for tag targeting, or to collect more data. For example, if tag T reports at times t=123, 178, and ,181, the location service may conclude that it is missing some tag reports for T during times t=[124, 177], so that it may page any tag reports in the range of 124 to 177. In another example, if the timestamp t in the tag report is encoded as a sequence number (counter), and the location service has tag reports for t=123, 125, 126, it may page any tag report that is missing sequence number t=124.

[0517] In an optional embodiment, the tag may implement security measures to avoid battery drain attacks caused by an attacker sending many meaningless indirect paging requests into the network, where the number of such requests may be limited to a maximum of N per time unit, with N being a preconfigured value (e.g., for a 10 minute time unit, N=2).

[0518] Tag for acting as NR Sidelink SyncRef UE but not as SL-UE or Relay UE

[0519] In an example embodiment, some tags with higher capabilities (e.g., larger battery capacity or energy supply from the environment (e.g., solar energy) for a specific period of time) can act as NR sidelink SyncRef UEs to help synchronize other nearby tags that are OoC. By being used to provide SyncRef signals, these SyncRef tags do not need to act as a full sidelink UE (i.e., SL-UE) or relay UE (see 3GPP TS 38.331 (Release 16)). Although no specific changes are required to provide basic SyncRef UE functionality, the simplified / lower energy SyncRef UE approach may require tags to act as NR sidelink SyncRef UEs while maintaining their low energy and / or low-cost hardware attributes compared to the current 3GPP-specified approach. SyncRef-capable tags can automatically turn on and off the transmission of their NR sidelink synchronization signals (or corresponding simplified / lower energy synchronization signals) based on the local availability of other SyncRef UEs in combination with the internal availability of sufficient energy to operate as a SyncRef UE.

[0520] In summary, this document describes a system and method for managing and configuring a communication device with a positioning function in a cellular communication network, which positioning function works in conjunction with other communication devices to report the location of the communication device to a location service. In particular, the present invention relates to a tag as a communication device, which can be a low-power, low-complexity tag. Active time window synchronization can be provided so that the tag can "sleep" most of the time to save energy. Privacy and security of data reported by the tag can be achieved: each tag can report its identity through the result of a cryptographic function calculation, so that only the location service can deduce the true / real tag identity by combining all collected tag reports with knowledge of the tag identifier (for example, from a secure database). Reports from out-of-coverage tags can be relayed by in-coverage tags to improve the overall reliability and coverage area where location services can be provided.

[0521] The entire system operation for a specific tag can be recaptured as follows:

[0522] - Tags send secure tag reports (report messages) in a periodic manner (e.g., via SL Discovery messages);

[0523] - Tag reports are collected by a node such as a collecting gNB, and / or collecting "tag" UEs, and / or collecting SL-UEs, and / or other collecting UEs that do not use SL in the case where the invention is implemented using a type of radio interface other than "SL". The collecting UE collects tag reports by creating tag sightings (observation reports) containing metadata about the received tag reports, and reports the tag sightings directly to the location service, and / or to a gNB in ​​the coverage area, which in turn forwards the received tag sightings (including its own generated tag sightings) to the location service:

[0524] Collecting (Tags) UEs not in gNB coverage may include tag targeting in their own tag reports sent to neighboring tags;

[0525] In some specific cases, a collecting (tag) UE in gNB coverage may include tag targeting, e.g. to include a digest of the tag targeting, which signals to OoC UEs that they may start using the digest version of the tag targeting therein;

[0526] - The location service then extracts / estimates the location and / or location trajectory of each tag based on the combined location of the collecting nodes that report them, including both the collecting gNB and the collecting UE;

[0527] If the collecting UEs have unknown locations (e.g. because they are themselves tags), the location service can also estimate these locations. In general, this involves solving a multivariable nonlinear optimization problem with applied noisy / sparse data inputs and parameter constraints. The use of a maximum likelihood estimation model may be useful for solving this optimization problem;

[0528] - The location service then provides information about the identified tags and their estimated locations to authorized clients, with each client receiving information only for the subset of tags for which the client is authorized.

[0529] Note that even if the tag itself cannot directly reach an in-coverage collecting UE or gNB, other nearby tags can collect tag reports including those targeted by the embedded tag and then forward them to any gNB (if possible) or otherwise to an in-coverage collecting UE, and thus to the corresponding gNB.

[0530] Although some embodiments of the present invention are described based on tag location, it should be noted that other tag applications are not excluded. The tag can be read to obtain the characteristics of the tag. The characteristics may include the identity of the tag. By knowing which base station the identity of the tag is delivered to, it may be possible to infer the (rough) location of the tag. The characteristics may also include the device type, referring to the type of device it belongs to or the type of device / product it is connected to.

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

[0532] Although some embodiments are described for sidelink communications, the present invention may also be implemented based on already existing 5G ProSe functionality (e.g., as found in 3GPP TS 24.554 (Release 17)), as described below:

[0533] - A single ProSe Discovery Relay Service Code (RSC) may be linked to a specific set of discovery keys. A specific RSC may determine a specific group of tags that collaboratively assist each other in determining location, and each tag may have a different Discovery User Integrity Key (DUIK) DUIK_i. This DUIK_i may effectively play the role of a tag-temp-id, or the tag-temp-id may be derived from the DUIK_i. Using this specific DUIK_i, the tag may sign the discovery message with a message integrity code (MIC), MIC_i;

[0534] - If there is a DUIK_i per tag i, the DDNMF network function can iterate over all DUIKs associated with the RSC to identify a DUIK that can be used to verify the MIC. Note that the MIC in the current 3GPP ProSe specification is only 32 bits, and if there are a large number of devices in the group, for example, 2^16 devices, each with a different DUIK_i key, it is likely that two devices at some point will generate the same MIC:

[0535] Therefore, a longer MIC may need to be specified for the ProSe specification for this purpose, or a restriction on the tag group size may be required;

[0536] Another option could be that if a tag identity conflict is suspected, its identity could be verified by requesting or obtaining another discovery message from the same tag at a later point in time. Since the MIC_i can then be calculated using a different UTC timer, the MIC_i will be different and thus the same conflict may not occur again, so that the actual identity of the device can be retrieved retroactively;

[0537] -The problem with using DUIK_i to identify a tag is that a monitoring UE receiving a discovery message cannot actually check if the tag is authentic. Therefore, all discovery messages may need to be sent to the CN / location service for verification, and this may be a problem (e.g., Denial of Service (DoS) attack risk). A solution may then be to keep the DUIK for its original purpose as defined by the 3GPP specification, i.e., use a single DUIK associated to the RSC to verify received messages and have the monitoring UE verify it as a first line of defense such as against DoS attacks. The tag and LMF have different unique keys (or tag-temp_id as described in the above example embodiments of the present invention) to create a security envelope that allows the location service to verify the identity of the tag;

[0538] - The confidentiality option of ProSe restricted discovery may be used, in which case the discovery messages may be encrypted. Assuming that all tags in a tag group use the same discovery user confidentiality key (DUCK), the DUCK may be used to encrypt the tag's tag-temp-id or its fixed tag id. The LMF may then be responsible for decryption and the DUCK should not be provided to the monitoring UE. Therefore, tags in other groups may help receive messages for tags and forward these messages to the LMF (location services);

[0539] 5G ProSe may specify rather large configuration bits for the UE (e.g. regarding identifiers, keys, etc.), making the tag unnecessarily complex and causing the tag to use more energy than strictly necessary. Therefore, as an alternative to explicit configuration during operation, factory / vendor pre-configured tags may be considered instead. This means that the tag may be pre-configured with a fixed tag id, and the tag may keep sending this ID in a secure manner, or may send a tag-temp-id that is securely derived from the tag id:

[0540] Operators can ship pre-configured tags to customers who purchase them and can attach the tags to items for tracking. Customers can then track the tags by using their own infrastructure (e.g., their own UEs), or by renting the operator's infrastructure, or a combination of both. To do this, a secure communication channel may need to be established between the supplier / operator and the customer to communicate the tag id of the purchased tag;

[0541] - An additional or alternative solution for obtaining an unconfigured tag could be to use ProSe discovery messages to (re)configure the tag:

[0542] For example, at a vendor or in a factory at a customer site, once the tags have been purchased, the owner / operator may send a ProSe restricted discovery (Model B) message with new (configuration) parameters for the tags. For example, these parameters may include an updated identity (tag id) or other relevant parameters such as RSC of the tag group, key material, etc. The reply to this message may be an acknowledgement in the form of a discovery message to confirm that the new configuration has been applied. Thus, tags may only send / receive discovery messages, and they may not need to implement any other type of communication (e.g., UL, DL, ProSe L direct communication, etc.) to simplify the tag design and reduce its cost.

[0543] The present invention may also be implemented by combining one or more of the above example embodiments using 5G ProSe and example embodiments using non-5G ProSe. In this case, the tag-temp-id identity of the tag may be linked to or derived from the 3GPP-defined credentials and 3GPP-defined keys for the UE, for example.

[0544] In addition, the present invention can be applied to low-cost, low-power tag tracking systems integrated into existing cellular network infrastructure (e.g., 5G, 6G), where the tags can be mobile, or static / fixed, or semi-static / semi-fixed.

[0545] In particular, example embodiments of the present invention may be applied in at least the following domains:

[0546] - IoT applications involving low-cost IoT sensor tags embedded in the environment (e.g., smart cities):

[0547] Where energy for tag operation can be harvested from the environment and / or from batteries that last for many years;

[0548] Used in moving goods / objects / vehicles for industrial applications;

[0549] -Logistics for tracking goods:

[0550] ·Labels can be embedded in packages or containers;

[0551] During some periods (e.g., in a container at sea), very limited location updates are needed. Verifying that the package remains in proximity to other packages may be sufficient. During other periods (e.g., transfers at a logistics center), more frequent location / status updates may be needed;

[0552] Sensors in tags can report on the condition of the goods (e.g., temperature, freshness, or motion experienced);

[0553] Anti-theft tags;

[0554] -Indoor positioning system;

[0555] -Hospital logistics for location tracking of goods, equipment, and personnel.

[0556] According to the study of the drawings, the present disclosure and the appended claims, those skilled in the art can understand and implement other variations of the disclosed embodiments when practicing the claimed invention. In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude multiple, so that "a" or "an" can correspond to "one or more". The foregoing description details certain embodiments of the present invention. However, it should be understood that no matter how detailed the foregoing content appears in the text, the present invention can also be practiced in many ways and is therefore not limited to the disclosed embodiments. It should be noted that the use of specific terms in describing certain features or aspects of the present invention should not be considered to mean that the terms are redefined herein to be limited to include any specific characteristics of the features or aspects of the present invention associated with the term. In addition, in the case of using a convention similar to "at least one of A, B, and C, etc.", generally, this construction is intended to make the skilled person understand the convention, for example, "a system having at least one of A, B, and C" will include but is not limited to systems having only A, only B, only C, A and B together, A and C together, B and C together and / or A, B, C together, etc. Where a convention similar to "at least one of A, B, or C, etc." is used, generally, such construction is intended to allow one skilled in the art to understand the convention, e.g., "a system having at least one of A, B, or C" would include, but is not limited to, systems having only A, only B, only C, A and B together, A and C together, B and C together, and / or A, B, C together, etc. One skilled in the art would further understand that virtually any disjunctive word and / or phrase presenting two or more alternative terms, whether in the specification, claims, or drawings, should be understood to contemplate the possibility of including one of the terms, either of the terms, or both of the terms. For example, the phrase "A or B" would be understood to include the possibility of "A" or "B" or "A and B."

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

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

Claims

1. A communication device (401) in a wireless network, wherein: To determine the characteristics of the communication device (401), the communication device (401) as a node is adapted to: generating a first security report message (430); receiving configuration information (432) directly or indirectly from a base station device (421); and sending the first safety report message (430), The configuration information (432) includes at least information about at least the following items: a time window during which the communication device (401) is suitable for sending the first security report message (430) to the base station device (421) and / or to another node and receiving a second security report message from the other node, and / or a frequency resource during which the communication device (401) is suitable for sending the first security report message (430) to the base station device (421) and / or to another node and receiving a second security report message from the other node.

2. The communication device (401) according to claim 1, wherein: The sending of the first safety report message (430) is performed at a time window and / or using a frequency resource depending on an identifier, communication device parameters or other implicit / explicit indications.

3. The communication device (401) according to any one of the preceding claims, wherein: The communication device (401) is adapted to: receiving the second safety report message (435) from one or more other nodes (411); In response to receiving at least some of the second safety report messages (435), generating corresponding observation reports associated with receiving the at least some of the second safety report messages (435); as well as The observation report is selectively embedded in the first safety report message (430).

4. The communication device (401) according to any one of the preceding claims, wherein: The communication device is suitable for: When the communication device is within the coverage of the synchronization source, receiving a timing reference from a synchronization signal; as well as When the communication device is not in coverage of a synchronization source, a timing reference is inferred based on receiving at least one second safety report message from at least one nearby node of the one or more other nodes.

5. The communication device (401) according to any one of the preceding claims, wherein: The communication device is suitable for: The received configuration information is embedded in the first security report message as a configuration data field.

6. The communication device (401) according to claim 5, wherein: The configuration data field includes at least a predefined target quantity type to control and / or influence and / or constrain the size of the first safety report message.

7. The communication device (401) according to any one of the preceding claims, wherein: The communication device is suitable for: The transmission power used to send the first safety report message is controlled by using a predefined transmission control policy determined based on the received configuration information (432).

8. The communication device (401) according to any one of the preceding claims, wherein: The first security report message includes at least a security portion data field that is an output of a cryptographic function over a plurality of data items.

9. The communication device (401) according to claim 8, wherein: The plurality of data items of the security portion data field include at least a temporary identifier of the communication device.

10. The communication device (401) according to any one of the preceding claims, wherein: The communication device is suitable for: embedding a payload in the first security report message; and The first security report message is sent including an embedded payload, the payload being an output of a locally computed cryptographic function.

11. A communication device (401) according to claim 3 or any of the preceding claims when dependent on claim 3, wherein: Selectively embedding the observation report in the first safety report message includes: selecting among the observation reports said observation reports which have been previously sent a number of times less than a predefined threshold; and / or selecting a more recent observation report among said observation reports; and / or selecting among the observation reports an observation report that does not have an indication that the selected observation report has been sent by a node within the coverage area of ​​the base station device, and / or Select an observation that has been flagged or identified as high priority. as well as The selected observation report is included in the first safety report message to be sent.

12. The communication device (401) according to claim 3 or any one of claims 1 to 10 dependent on claim 3, wherein: Selectively embedding the observation report in the first safety report message includes: selecting among the observation reports said observation report which has previously been sent a number of times equal to or greater than a predefined threshold; and / or selecting an older observation report among said observation reports; and / or as well as The selected observation reports are prevented from being embedded in the first safety report message to be sent as part of the first safety report message during the time window, while the unselected observation reports are sent in the observation report.

13. The communication device (401) according to any one of the preceding claims, wherein: The communication device is suitable for: If no time slots within the time window and on the transmission frequency channel of the frequency resource are free, or if the percentage of occupied time slots within the time window is above a predefined threshold, the time window itself is automatically extended.

14. The communication device (401) according to any one of the preceding claims, wherein: The communication device is suitable for: If the communication device is located on a cell boundary, receiving another configuration information from another base station device, the cell boundary separating a cell in the coverage of the base station device from another cell in the coverage of the another base station device, the another configuration information comprising at least information about another time window during which the communication device is suitable for sending and receiving and about other frequency resources suitable for the communication device to use for sending and receiving; as well as Conditionally sending during both the time window and the another time window.

15. A method of determining characteristics of a communication device (401) as a node in a wireless network, wherein: The method comprises: generating a first security report message (430); If the communication device (401) is within the coverage of the base station device (421), directly receiving configuration information (432) from the base station device (421); and sending the first safety report message (430), The configuration information (432) includes at least information about at least the following items: a time window during which the communication device (401) is suitable for sending the first security report message (430) to the base station device (421) and / or to another node and receiving a second security report message from the other node, and / or a frequency resource during which the communication device (401) is suitable for sending the first security report message (430) to the base station device (421) and / or to another node and receiving a second security report message from the other node.

16. A system comprising: In a wireless network, at least a plurality of communication devices (401), a plurality of base station devices (421) and a core network location service (440, 441) adapted to determine a location estimate of a target communication device among the plurality of communication devices (401) according to any one of claims 1 to 14, wherein the core network location service is adapted to receive a security report message sent as a unicast message from a communication device among the plurality of communication devices, or to receive a variant of the security report message directly from the base station device if a base station device among the plurality of base station devices receives the security report message from the communication device within the coverage of the base station device, the variant of the security report message corresponding to the security report message or at least one security element thereof embedded in an observation report generated by the base station device.

Images