Generation and maintenance of temporary identifiers for ambient internet-of-things devices

Abstract

Technology disclosed herein relates to generation and maintenance of a temporary identifier of an ambient internet-of-things (AIoT) device. An example method of wireless communication includes receiving, by a wireless device from a reader device, a first message; obtaining a temporary identifier of the wireless device by deriving, by the wireless device, the temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; and transmitting, by the wireless device to the reader device, a second message relating to the first message, the second message containing the temporary identifier.

Description

GENERATION AND MAINTENANCE OF TEMPORARY IDENTIFIERS FOR AMBIENT INTERNET-OF-THINGS DEVICESTECHNICAL FIELD

[0001] This document is directed generally to wireless communications.BACKGROUND

[0002] Wireless communication technologies are moving the world toward an increasingly connected and networked society. The rapid growth of wireless communications and advances in technology has led to greater demand for capacity and connectivity. Other aspects, such as energy consumption, device cost, spectral efficiency, and latency are also important to meeting the needs of various communication scenarios. In comparison with the existing wireless networks, next generation systems and wireless communication techniques need to provide support for an increased number of users and devices, as well as support an increasingly mobile society.SUMMARY

[0003] Various techniques are disclosed related to the generation, management, and secure updating of temporary identifiers for Artificial Intelligence of Things (AIoT) devices. that can be implemented by embodiments in mobile communication technology, including various protocol suites specified by the Third Generation Partnership Project (3GPP) , e.g., within the 5G System (5GS) architecture for AIoT.

[0004] In one example aspect, a wireless communication method is disclosed. The method includes: receiving, by a wireless device from a reader device, a first message; obtaining a temporary identifier of the wireless device by deriving, by the wireless device, the temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; and transmitting, by the wireless device to the reader device, a second message relating to the first message, the second message containing the temporary identifier.

[0005] In another example aspect, a wireless communication method is disclosed. The method includes: transmitting, by a network function to a reader device, a first message relating to a wireless device; obtaining a first temporary identifier of the wireless device by deriving, by the network function, the first temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; and receiving, from the reader device, a second message relating to the first message, the second message containing a second temporary identifier of the wireless device derived by the wireless device using the cryptographic function based on the identifier of the wireless device and the freshness parameter.

[0006] In a further example aspect, a wireless communication method is disclosed. The method includes: transmitting, by a reader device to a wireless device, a first message; and transmitting, by the reader device to a network function, a second message relating to the first message, the second message containing a temporary identifier of the wireless device derived by the wireless device using a cryptographic function based on an identifier of the wireless device and a freshness parameter.

[0007] In yet another exemplary aspect, the above-described methods are embodied in the form of at least one computer-readable medium that stores processor-executable code that, upon execution by one or more processors, cause an apparatus to implement the method.

[0008] In yet another exemplary embodiment, a device that is configured or operable to perform the above-described methods is disclosed. The device comprises at least one processor configured to implement the method.

[0009] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] Figure 1 shows an example network architecture.

[0011] Figures 2-5 show example signal exchange diagrams according to some embodiments.

[0012] Figures 6-8 show flowcharts illustrating example processes according to some embodiments.

[0013] Figure 9 is a block diagram example of a wireless communication system according to some embodiments.

[0014] Figure 10 is a block diagram of an example hardware platform according to some embodiments.DETAILED DESCRIPTION

[0015] Section headings are used in the present document only to improve readability and do not limit scope of the disclosed embodiments and techniques in each section to only that section. Certain features are described using the example of Fifth Generation (5G) wireless protocol. However, applicability of the disclosed techniques is not limited to only 5G wireless systems.

[0016] Initial discussion

[0017] Recently, 3GPP has introduced a class of devices called ambient internet-of-things (AIoT) devices. These devices are typically intended to provide communication connectivity without needing local energy source such as a battery, which may need maintenance and operation. The AIoT devices are intended to operate by consuming very low power (e.g., 1 to 100 microWatts) and may be powered up only during actual communication usage. It is expected that such devices can provide more versatile and ubiquitous deployments than present day technologies such as QR codes, barcodes or radio frequency tags (RFID) .

[0018] The AIoT devices may be configured to operate in a communication network by supporting a number of services. For example, an inventory service is a fundamental process for AIoT devices, which includes both “inventory only” and “inventory and command” cases. In both scenarios, the steps traditionally involve AIoT paging and permanent Device ID transmission. The AIoT paging message may contain an ID of a single AIoT device, a group ID that maps to multiple AIoT devices, or multiple IDs of AIoT devices. If the AIoT paging message does not contain an ID, it will map to all the AIoT devices. After these steps, the network can calculate the quantity of device IDs for this inventory.

[0019] Privacy aspects of AIoT device identifiers are addressed in TR 33.713 (KI#3) . Without proper privacy protection mechanisms, attackers can identify, monitor, and track AIoT devices based on their associated identifiers during normal communication procedures such as inventory operations. This creates substantial privacy and security risks for both individual devices and the broader AIoT ecosystem. The transmission of permanent Device IDs or group IDs in plaintext or even using simple encryption schemes remains vulnerable to various monitoring and tracking attacks, potentially exposing sensitive information and operational patterns to unauthorized parties. These vulnerabilities manifest in various real-world scenarios with significant business and security implications.

[0020] For example, the inventory device quantity may contain business information, such as the quantity of stock in a shopping mall. If this information falls into the hands of competitors, they may adjust their sales strategy to attract more customers from that shopping mall.

[0021] As another example, by broadcasting a fake inventory message with a group ID, an attacker could potentially calculate the quantity of devices in a group by observing the differences in reported device IDs, even if the IDs are encrypted. This could lead to the exposure of the inventory device quantity associated with the group ID. For example, in a shopping mall, assuming the attacker has knowledge of the link between the group ID and goods (such as knowledge of the link between SUPI and the real subscriber) , the attacker could use a fake reader to broadcast this group ID. Subsequently, the attacker would receive multiple device IDs and calculate the device quantity for this group ID, allowing them to determine the number of specific goods.

[0022] As a further example, an attacker could calculate the quantity of all devices by observing differences in reported device IDs, even if the IDs are encrypted, after sending a fake inventory message without any IDs. This could result in the exposure of the inventory device quantity within an area. For instance, in a shopping mall, if an attacker can control the broadcast scope into the shopping mall, they could utilize a fake reader to broadcast an inventory message without any ID. Subsequently, the attacker would receive multiple device IDs, enabling them to calculate the device quantity in this area and determine the stock levels of all the goods of this shopping mall.

[0023] The disclosed technology addresses these and other privacy concerns by replacing permanent Device IDs with temporary identifiers (Temp IDs) during communications. These Temp IDs are derived using cryptographic functions with freshness parameters and can be dynamically updated through procedures initiated by either a Reader or the AIoT Function (AIoTF) . This approach prevents unauthorized tracking while maintaining the network's ability to uniquely identify and communicate with devices during inventory and command operations.

[0024] Introduction

[0025] With reference to the network architecture in Figure 1, some embodiments are disclosed using examples of functional entities defined in 3GPP TS 23.501. For clarity and to depict the reference point architecture, the AMF, Nx, and N2 as depicted using dashed lines, as all deployments may not use them. Ambient IoT Function (AIOTF) is introduced to support AIoT services, with some AMF's functionalities integrated, which includes:

[0026] Various aspects of the disclosed techniques are described through several example embodiments. It will be understood that the example embodiments are presented as different sections only for ease of reading and do not limit scope of the disclosed techniques to the embodiment in which the technique is disclosed. Furthermore, these embodiments are disclosed with reference to Figures 2 to 5 that depict messages exchanged among various actors operating in a communication network including AIOT device 152, Reader 154, AIoTF 156, and AF 158. Reader 154 may be user equipment (UE) .

[0027] Example Embodiment 1: Temp ID generation using RAND / Time stamp.

[0028] Figure 2 shows an example signal exchange diagram of a procedure for initial Temp ID generation using RAND / Time stamp according to some embodiments.

[0029] At 210, AF 158 sends an AIoT service request (e.g., inventory or command request) to AIoTF 156, including identifier information relating to one or more AIoT devices. The identifier information may include one or more device IDs (e.g., one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices) .

[0030] At 220, AIoTF 156 derives Temp ID based on Ks and RAND / Time stamp (i.e. RAND or Time stamp) , for example, Temp ID=HMAC (device ID, RAND / Time stamp) , the input key (or referred to as “key” for brevity) is Ks. In some embodiments, RAND is a random number. In some embodiments, Time stamp is a constant related to the current time, for example, the current UTC-based time. In some embodiments, AIoTF 156 may obtain the key from AIoT Data Management (ADM) .

[0031] At 230, AIoTF 156 sends a first AIoT service request message to Reader 154. The first AIoT service request message includes information regarding the service request and the RAND / Time stamp which is used to derive Temp ID in step 2 at 220.

[0032] At 240, Reader 154 transfers a second AIoT service request message. The second AIoT service request message may be the same as or similar to the first AIoT service request message that Reader 154 receives from AIoTF 156 at 230. In some embodiments, the second AIoT service request message to AIoT device 152 omits identifier information and does not include a device ID, or a device ID list, or a group ID.

[0033] At 250, AIoT device 152 derives Temp ID using received RAND / Time stamp in the second AIoT service request message from Reader 154. The derivation may be based on the same function and same input as the deviation by AIoTF 156 at 220. In some embodiments, AIoT device 152 may be pre-configured with Kaiot, and may derive, based on Kaiot, Ks as input key to the function. The Temp ID derived at 250 may be identical to the Temp ID derived at 220.

[0034] At 260, AIoT device 152 sends a service response (e.g., inventory or command response) to Reader 154 with its Temp ID derived at 250.

[0035] At 270, Reader 154 transfers to AIoTF 156 the service response (e.g., inventory or command response) with the Temp ID.

[0036] At 280, if a service response (e.g., inventory or command response) is received, AIoTF 156 stores the Temp ID of AIoT device 152 in the service response for later use. In some embodiments, AIoTF 156 confirms that a received Temp ID (that AIoT device 152 has derived at 250) matches the Temp ID that AIoTF 156 has derived for the same AIoT device 152 at 220 before AIoTF 156 stores the received Temp ID.

[0037] Temp ID is derived as follows.

[0038] Temp ID=F (ID, freshness parameter) and input key.

[0039] F is a service specific function that generates a temp ID. For example, F includes a Hash-based Message Authentication Code (HMAC) algorithm as defined in TS 33.210. F may be pre-configured on AIoT device 152 and AIoTF 156.

[0040] The ID and freshness parameter are used as input of F. For example, ID is device ID or temp ID of AIoT device 152; the freshness parameter includes RAND, a Time Stamp, or a counter value.

[0041] In some embodiments, the input key is Ks. In some embodiments, AIoT device 152 may be pre-configured with Kaiot, and may derive Ks based on Kaiot. In some embodiments, AIoTF 156 may obtain Ks from ADM.

[0042] Only one AIoT device 152 is depicted in Figure 2 for illustration purposes and not intended to be limiting. Reader 154 may be associated with or manage multiple AIoT devices. In some embodiments, multiple AIoT devices are identified in the service request from AF 158 to AIoTF 156 at 210 using, e.g., a device ID list or group ID. AIoTF 156 derives Temp IDs for the identified multiple AIoT devices at 220 (e.g., one Temp ID for each of the multiple AIoT devices) , and transmits to Reader 154 a first service request message containing the device ID list or group ID used in deriving the Temp IDs at 230. Reader 154 sends a second service request message containing the device ID list or group ID at 240. The second AIoT service request message may be identical or similar to the first AIoT service request message that Reader 154 receives from AIoTF 156 at 230. All or a sub-group of the AIoT devices identified by the device ID list or group ID responds by deriving respective Temp IDs at 250 and sending to Reader 154 a service response including the derived Temp IDs at 260. Reader 154 sends to AIoTF 156 the received service response including the Temp IDs at 270. AIoFT 156 stores the received Temp IDs at 280. Depending on how many AIoT devices have responded, the Temp IDs stored at 280 may be a sub-group of the Temp IDs AIoFT 156 has generated at 220. In some embodiments, AIoTF 156 confirms that a received Temp ID (that AIoT device 152 has derived) matches the Temp ID that AIoTF 156 has derived for the same AIoT device (e.g., with the same device ID) at 220 before AIoTF 156 stores the received Temp ID.

[0043] In some embodiments, the Temp ID of AIoT device 152 stored in a storage device of or accessible by AIoTF 156 may remain valid and be used in normal operations until the Temp ID is updated (e.g., upon a request as described elsewhere in the present document) or revised otherwise, e.g., during a period between the generation of a Temp ID and its subsequent update, or between consecutive updates. For example, during such a period, AF 158 sends an AIoT service request (e.g., inventory or command request) to AIoTF 156, including one or more device IDs (e.g., one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices) . The service request may include Ks.In the absence of an update request from, e.g., AIoTF 156 or Reader 154 (see, e.g., Figures 3 and 4) , AIoTF 156 does not derive a new Temp ID for AIoT device 152 identified in the service request. Instead, AIoTF 156 retrieves, using the received device ID, the corresponding previously generated Temp ID from a storage device. The retrieved Temp ID, instead of the permanent Device ID (or group ID) , may be used in subsequent communications with respect to this AIoT service request. AIoTF 156 sends a first AIoT service request message to Reader 154. The message includes information regarding the AIoT service request and the retrieved Temp ID.Reader 154 transfers a second AIoT service request message. The second AIoT service request message may be identical or similar to the first AIoT service request message. Based on the second AIOT service request message, AIoT device 152 with the matching Temp ID included in the second AIOT service request message sends a service response (e.g., inventory / command response) to Reader 154. The response may include the Temp ID of AIoT device 152. Reader 154 transfers the service response to AIoTF 156. In some embodiments, AIoTF 156 verifies that the received Temp ID matches the one that AIoTF 156 has retrieved for AIoT device 152 and included in the first AIoT service request message to Reader 154.

[0044] Figure 3 shows an example signal exchange diagram of a procedure for updating a Temp ID using RAND / Time stamp triggered by Reader 154, according to some embodiments.

[0045] At 310, Reader 154 generates a random number (RAND) or a current Time stamp to trigger or initiate a Temp ID update for AIoT device 152. A Temp ID update occurs based on a Temp ID update request message including a RAND or Time stamp transmitted from Reader 154 to AIoTF 156 and AIoT device 152 as described below.

[0046] At 320, Reader 154 sends a first Temp ID update request message to AIoTF 156. The first Temp ID update request message includes the generated RAND or Time stamp. The first Temp ID update request message may contain one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices. If the first Temp ID update request message does not contain an ID, it will map to all the AIoT devices under Reader 154. In some embodiments, the message may contain a reader ID of Reader 154.

[0047] At 330, AIoTF 156 derives an updated Temp ID based on the received device ID and RAND / Time stamp. If AIoTF 156 identifies a Temp ID generated previously (e.g., previously generated or stored in a storage device of or accessible by AIoTF 156) that corresponds to device ID, the previously generated Temp ID can be used as input for the derivation process instead of the device ID.

[0048] At 340, AIoTF 156 sends a Temp ID update response to Reader 154. The Temp ID update response may include confirmation or acknowledgment of the update request, and / or indication of successful processing of the requested Temp ID update.

[0049] At 350, Reader 154 sends a second Temp ID update request message to AIoT device 152. The second Temp ID update request message is the same as or similar to the first Temp ID update request message in step 2 at 320. The second Temp ID update request message includes the generated RAND or Time stamp. The second Temp ID update request message may contain one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices. If the second Temp ID update request message does not contain a device ID, it will map to all the AIoT devices under Reader 154.

[0050] At 360, AIoT device 152 derives an updated Temp ID using the received RAND / Time stamp. The derivation may be based on the same function and same input as the deviation by AIoTF 156 at 330. The updated Temp ID generated at 360 may be identical to the updated Temp ID generated at 330.

[0051] At 370, AIoT device 152 sends a Temp ID update response to Reader 154 with its updated Temp ID.

[0052] At 380, after receiving the response, Reader 154 sends a notification message to AIoTF 156, including the updated Temp ID.

[0053] At 390, if a notification message is received, AIoTF 156 stores the Temp ID of AIoT device 152 for later use. In some embodiments, AIoTF 156 confirms that a received updated Temp ID (that AIoT device 152 has derived at 360) matches the updated Temp ID that AIoTF 156 has derived for the same AIoT device (e.g., with the same device ID) at 330 before AIoTF 156 stores the received Temp ID.

[0054] Only one AIoT device 152 is depicted in Figure 3 for illustration purposes and not intended to be limiting. Reader 154 may be associated with or manage multiple AIoT devices. In some embodiments, multiple AIoT devices are identified in a temp ID update request that Reader 154 generates at 310 and transmits to AIoTF 156 at 320. The multiple AIoT devices may be identified using, e.g., a device ID list or group ID in the Temp ID update request. AIoTF 156 derives updated Temp IDs for the identified multiple AIoT devices at 330 (e.g. one updated Temp ID for each of the multiple AIoT devices) , and transmits to Reader 154 the temp ID update response containing the device ID list or group ID used in deriving the Temp IDs at 340. Reader 154 sends a Temp ID update request containing the device ID list or group ID at 350. All or a sub-group of the AIoT devices identified by the device ID list or group ID respond by deriving respective updated Temp IDs at 360 and sending to Reader 154 a Temp ID update response including the derived updated Temp IDs at 370. Reader 154 sends to AIoTF 156 a notification including the updated Temp IDs at 380. AIoFT 156 stores the received updated Temp IDs at 390. Depending on how many AIoT devices have responded to the Temp ID update request from Reader 154, the updated Temp IDs stored at 390 may be a sub-group of the updated Temp IDs that AIoFT 156 has generated at 330. In some embodiments, among the received one or more updated Temp IDs, AIoTF 156 confirms that a received updated Temp ID (that an AIoT device has derived at 360) matches the updated Temp ID that AIoTF 156 has derived for the same AIoT device (e.g., with the same device ID) at 330 before AIoTF 156 stores the received Temp ID.

[0055] Figure 4 shows an example signal exchange diagram of a procedure for updating a Temp ID using RAND / Time stamp triggered by AIoTF 156, according to some embodiments.

[0056] At 410, AIoTF 156 generates a random number (RAND) or a current Time stamp to trigger or initiate a Temp ID update for AIoT device 152.

[0057] At 420, AIoTF 156 derives an updated Temp ID based on a device ID and RAND / Time stamp. If AIoTF 156 identifies a Temp ID generated previously (e.g., previously generated or stored in a storage device of or accessible by AIoTF 156) that corresponds to the device ID, the previously generated Temp ID can be used as input for the derivation process instead of the device ID.

[0058] A Temp ID update occurs at AIoT device 152 based on a Temp ID update request message including the RAND or Time stamp transmitted from AIoTF 156 to AIoT device 152 via Reader 154, as described below.

[0059] At 430, AIoTF 156 sends a first Temp ID update request message to Reader 154, including RAND / Time stamp. The first Temp ID update request message may contain one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices. If the first Temp ID update request message does not contain an ID, it will map to all AIoT devices under Reader 154.

[0060] At 440, Reader 154 transfers a second Temp ID update request message. The second Temp ID update request message is identical or similar to the first Temp ID update request message that Reader 154 receives from AIoTF 156 at 420. The second message includes a RAND or Time stamp. The second Temp ID update request message may contain one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices. In some embodiments, the second message may omit identifier information and does not contain any ID. Reader 154 transmits the second message to all the AIoT devices under or managed by Reader 154.

[0061] At 450, AIoT device 152 derives an updated Temp ID using the received RAND / Time stamp. The derivation may be based on the same function and same input as the deviation by AIoTF 156 at 420. The updated Temp ID generated at 450 may be identical to the updated Temp ID generated at 420.

[0062] At 460, AIoT device 152 sends a Temp ID update response to Reader 154 with its updated Temp ID.

[0063] At 470, Reader 154 transfers the Temp ID update response to AIoTF 156.

[0064] At 480, if a Temp ID update response is received, AIoTF 156 stores the Temp ID of AIoT device 152 for later use. In some embodiments, AIoTF 156 confirms that the received updated Temp ID (that AIoT device 152 has derived at 450) matches the updated Temp ID that AIoTF 156 has derived for the same AIoT device 152 at 420 before AIoTF 156 stores the received updated Temp ID.

[0065] Only one AIoT device 152 is depicted in Figure 4 for illustration purposes and not intended to be limiting. Reader 154 may be associated with or manage multiple AIoT devices. In some embodiments, multiple AIoT devices are identified in a temp ID update request that AIoTF 156 generates at 410 and transmits to Reader 154 at 430 The multiple AIoT devices may be identified using, e.g., a device ID list or group ID in the Temp ID update request. AIoTF 156 derives updated Temp IDs for the identified multiple AIoT devices at 420 (e.g. one updated Temp ID for each of the multiple AIoT devices) , and transmits to Reader 154 the temp ID update response containing the device ID list or group ID used in deriving the Temp IDs at 430. Reader 154 sends a Temp ID update request containing the device ID list or group ID at 440. All or a sub-group of the AIoT devices identified by the device ID list or group ID respond by deriving respective updated Temp IDs at 450 and sending to Reader 154 a Temp ID update response including the derived updated Temp IDs at 460. Reader 154 sends to AIoTF 156 the Temp ID update response including the updated Temp IDs at 470. AIoFT 156 stores the received updated Temp IDs at 480. Depending on how many AIoT devices have responded to the Temp ID update request from Reader 154, the updated Temp IDs stored at 480 may be a sub-group of the updated Temp IDs that AIoFT 156 has generated at 420. In some embodiments, among the received one or more updated Temp IDs, AIoTF 156 confirms that a received updated Temp ID (that an AIoT device has derived) matches the updated Temp ID that AIoTF 156 has derived for the same AIoT device (e.g., with the same device ID) at 420 before AIoTF 156 stores the received Temp ID.

[0066] Example Embodiment 2: Temp ID generation and maintenance using counter.

[0067] Figure 5 shows an example signal exchange diagram of a procedure for generating and maintaining a Temp ID using a counter, according to some embodiments.

[0068] The initial counter value (COUNT) and counter increment value (N) may be pre-configured as constants in both AIoT device 152 (at 500-I) and AF 158 (at 500-II) . COUNT represents the starting value of the counter, while N denotes the value by which the counter is incremented during update operations. For example, COUNT may be configured as 0 and N as 1; however, either COUNT or N, or both parameters, may be configured with values different from those in this exemplary configuration.

[0069] At 510, AF 158 sends an AIoT service request (inventory or command request) to AIoTF 156, including identifier information relating to one or more AIoT devices. The identifier information may include one or more device IDs (one device ID of a single AIoT device, a device ID list of multiple AIoT devices, or a group ID that maps to a group of AIoT devices) . One or more counter parameters, such as COUNT and N, are also included in the message. The counter parameters may be used to determine a counter value to be used as a freshness parameter in deriving a Temp ID of AIoT device 152. The one or more counter parameters may be pre-configured on the AF 158.

[0070] At 520-I, AIoT device 152 derives a Temp ID based on the device ID and the pre-configured counter parameters (e.g., COUNT and N) and a function (e.g., an HMAC algorithm) . A key (e.g., Ks) may be used as another input to the function, along with the device ID and the pre-configured counter parameters. AIoT device 152 may derive the key based on Kaiot. Kaiot may be pre-configured in AIoT device 152. If AIoT device 152 has a Temp ID generated previously, the previously generated Temp ID can be used as input for the derivation process instead of the device ID at 520-I. In some embodiments, AIoT device 152 may save the counter value used in the current derivation for future use (e.g., an update in response to a received update indicator)

[0071] At 520-II, AIoTF 156 derives a Temp ID for AIoT device 152 based on the device ID and counter parameters included in the AIoT service request received from AF 158 and a function (e.g., an HMAC algorithm) . A key (e.g., Ks) may be used as another input to the function, along with the received device ID and the counter parameters. The key may be obtained from ADM. In some embodiments, the derivations at 520-I and 520-II may occur (substantially) concurrently.

[0072] In some embodiments, AIoT device 152 and AF 158 may be pre-configured with Kaiot, and may derive Ks based on Kaiot.

[0073] At 520-II, if AIoTF 156 identifies a Temp ID generated previously (e.g., previously generated or stored in a storage device of or accessible by AIoTF 156) that corresponds to the device ID, the previously generated Temp ID can be used as input for the derivation process instead of the device ID. In some embodiments, AIoF device 152 and AIoTF 156 may be pre-configured such that AIoF device 152 and AIoTF 156 derive an updated Temp ID for AIoF device 152 based on a same input with respect to device ID or Temp ID. For example, both AIoF device 152 and AIoTF 156 are pre-configured such that when a previously generated Temp ID is available, the Temp ID is used in deriving an updated Temp ID by AIoF device 152 and AIoTF 156, respectively.

[0074] For a normal procedure without Temp ID update or synchronization as illustrated in panel A of Figure 5:

[0075] At 530A, AIoTF 156 sends a first AIoT service request message to Reader 154. The first message includes the Temp ID or Temp ID list associated with AIoT device 152 generated in step 2 at 520-II.

[0076] At 540A, Reader 154 transfers a second AIoT service request message. The second message may be identical or similar to the first message that Reader 154 receives from AIoTF 156 at 530A.

[0077] At 550A, AIoT device 152 sends a service response to Reader 154 with its Temp ID that AIoT device 152 has derived at 520-I. The Temp ID may be previously generated and still valid at the time. Accordingly, AIoT device 152 does not derive a new Temp ID for providing the service response.

[0078] At 560A, Reader 154 transfers the service response to AIoTF 156 with the Temp ID that AIoT device 152 has derived at 520-I.

[0079] At 570A, if a service response is received, AIoTF 156 stores the Temp ID of AIoT device 152 and / or counter (counter=COUNT+N) for later use. In some embodiments, AIoTF 156 confirms that the Temp ID of AIoT device 152 in the received service response matches the Temp ID that AIoTF 156 has derived for the same AIoT device 152 at 520-II, or that AIoTF 156 has identified in the first AIoT service request message at 530A, before AIoTF 156 stores the received Temp ID. In some embodiments, AIoTF 156 omits the storage operation if the Temp ID may have been stored previously.

[0080] For procedure with Temp ID update as illustrated in panel B of Figure 5:

[0081] The counter-based Temp ID update may be triggered along with a service request from AF 158 received at 510. At 530B, AIoTF 156 sends a first AIoT service request message to Reader 154. The first AIoT service request message includes information of the service request. The first AIoT service request message includes the Temp ID (or Temp ID list) of AIoT device 152 generated in step 2 at 520-II. An update indicator ( “update ind” in panel B of Figure 5) is also included in the first AIoT service request message as an indication to trigger Temp ID update.

[0082] At 540B, Reader 154 transfers a second AIoT service request message with the update indicator. The second AIoT service request message may be identical or similar to the first AIoT service request message that Reader 154 receives from AIoTF 156 at 530B.

[0083] At 550B, when an update indicator is received, AIoT device 152 derives a new or updated Temp ID using a counter value (e.g., counter=counter+N) . In some embodiments, AIoT device 152 may save the counter value used in the current derivation for future use (e.g., a next update in response to a received update indicator) . The derivation for the Temp ID update may be based on a function (e.g., an HMAC algorithm) . In some embodiments, the Device ID of the AIoT device 152 may be used as input to the function. In some embodiments, if there is a corresponding Temp ID generated previously, the Temp ID can be used instead of device ID as the input. The function may be pre-configured on AIoT device 152. AIoT device 152 may derive Ks as input to the function, based on Kaiot that is pre-configured in the AIoT device 152.

[0084] At 560B, AIoT device 152 sends a response to Reader 154 with the new or updated Temp ID.

[0085] At 570B, Reader 154 transfers the response to AIoTF 156 with the new or updated Temp ID.

[0086] At 580B, AIoTF 156 stores the new or updated Temp ID of AIoT device 152 and updates its counter value to counter+N.

[0087] For procedure with Temp ID synchronization as illustrated in panel C of Figure 5:

[0088] The counter-based Temp ID synchronization may be triggered along with a service request from AF 158 received at 510. At 530C, AIoTF 156 sends a first AIoT service request message to Reader 154. The first AIoT service request message includes information of the service request. The first AIoT service request message includes the Temp ID or Temp ID list of AIoT device 152 generated in step 2 at 520-II. A synchronization indicator ( “sync ind” in panel C of Figure 5) is also included in the first AIoT service request message as an indication to trigger Temp ID synchronization.

[0089] At 540C, Reader 154 transfers a second AIoT service request message with the synchronization indicator. The second AIoT service request message may be identical or similar to the first AIoT service request message that Reader 154 receives from AIoTF 156 at 530C.

[0090] At 550C, once a synchronization indicator is received, AIoT device 152 derives a synchronized Temp ID using a counter value, e.g., counter=COUNT which is the initial value of the counter. The derivation for the synchronization may be based on a function (e.g., an HMAC algorithm) . In some embodiments, the Device ID of the AIoT device 152 may be used as input to the function. In some embodiments, if there is a corresponding Temp ID generated previously, the Temp ID can be used instead of device ID as the input. The function may be pre-configured on AIoT device 152. In some embodiments, AIoT device 152 may derive a key, Ks, as input to the function based on Kaiot that is pre-configured in AIoT device 152. In some embodiments, AIoT device 152 may save the counter value used in the current derivation (e.g., COUNT) for future use (e.g., an update in response to a received update indicator) .

[0091] At 560C, AIoT device 152 sends a response to Reader 154 with the synchronized Temp ID.

[0092] At 570C, Reader 154 transfers the response to AIoTF 156 with the synchronized Temp ID.

[0093] At 580C, AIoTF 156 stores the synchronized Temp ID of AIoT device 152 and update the counter value (e.g., by resetting its counter to COUNT) .

[0094] Only one AIoT device 152 is depicted in Figure 5 for illustration purposes and not intended to be limiting. Reader 154 may be associated with or manage multiple AIoT devices. In some embodiments, multiple AIoT devices are identified in the service request at 510. The multiple AIoT devices may be identified using, e.g., a device ID list or group ID. AIoTF 156 derives a list of Temp IDs for the identified multiple AIoT devices at 520-II (e.g. one Temp ID for each of the multiple AIoT devices) , and transmits to Reader 154 the temp ID list in the first AIoT service request message at 530A / 530B / 530C. At 540A / 540B / 540C, Reader 154 sends a second AIoT service request message to the identified AIoT devices. In some embodiment, the first or second AIoT service request message may include an update indicator or a synchronization indicator. All or a sub-group of the AIoT devices identified by the device ID list or group ID respond by providing a service response at 560A / 560B / 560C. If the second AIoT service request message includes an update indicator or a synchronization indicator, an AIoT device’s response may include deriving an updated Temp ID at 550B or a synchronized Temp ID at 550C, and the service response sent to Reader 154 at 560B / 560C includes the updated Temp ID or the synchronized Temp ID. Reader 154 relays to AIoTF 156 the service response at 570A / 570B / 570C. AIoFT 156 stores the received Temp IDs at 580A / 580B / 580C. Depending on how many AIoT devices have responded to the second AIoT service request message from Reader 154, the Temp IDs stored at 580A / 580B / 580C may be a sub-group of the Temp IDs that AIoFT 156 has derived at 520-II or included in the first AIoT service request message sent to Reader 154 at 530A / 530B / 530C.

[0095] Figure 6 shows a flowchart illustrating an example process for wireless communication performed by a wireless device according to some embodiments.

[0096] At 610 of process 600, the wireless device (e.g., 152) receives a first message from a reader device (e.g., 154) . In some embodiments, this first message is forwarded by a network function (e.g., 156) to reader device (e.g., 154) . The reader device may be a user equipment.

[0097] The first message may include or relate to a request (e.g., a service request, an update request, a synchronization request) with respect to one or more wireless devices. Accordingly, the first message may be a service request message, a temporary identifier update request message, or a message containing a temporary identifier update indicator or a temporary identifier synchronization indicator. This message may include a permanent device identifier of a wireless device, a plurality of permanent device identifiers of multiple wireless devices (including the specific wireless device) , or a group identifier corresponding to a group of wireless devices (including the specific wireless device) . If the first message includes no identifier, the first message may be transmitted by the reader device to all the wireless devices under the reader device. The derivation of a temporary identifier of the wireless device may be performed based on the permanent device identifier or a previously generated temporary identifier stored on the wireless device.

[0098] In some embodiments, the first message contains or relates to a service request associated with the wireless device, such as an inventory request or a command request. The service request may be provided by a second network function, e.g., an application function (AF) (e.g., 158) , to the network function. See, e.g., Figure 2 and the description thereof.

[0099] In other embodiments, the first message may contain a temporary identifier update request that includes a freshness parameter, such as a random number or a time stamp. This update request may be initiated by either the network function or the reader device, with the freshness parameter being generated by the component that initiates the update request. For example, when a temporary identifier update is initiated by the reader device, the reader device generates the freshness parameter. As anther example, when a temporary identifier update is initiated by the network function, the network function generates the freshness parameter. See, e.g., Figures 3 and 4 and the description thereof.

[0100] In some implementations, when utilizing a counter-based approach, the first message may omit the freshness parameter. The first message may include a service request, an update indicator, or a synchronization indicator. The counter value for temporary identifier generation, updating, or synchronization, may be determined by the wireless device based on one or more counter parameters pre-configured on the wireless device. Examples of the one or more counter parameters include at least one of an initial counter value (COUNT) or a counter increment value (N) . See, e.g., Figure 5 and the description thereof.

[0101] At 620 of process 600, the wireless device obtains a temporary identifier by deriving it using a cryptographic function based on an identifier of the wireless device and the freshness parameter.

[0102] The cryptographic function may include a hash-based message authentication code (HMAC) function using a key. The derivation process involves applying inputs including at least one of the freshness parameter, the identifier of the wireless device, or the key. The freshness parameter may be provided in the first message, or generated by the wireless device based on one or more pre-configured counter parameters, as described in 610. The identifier of the wireless device may be a permanent device identifier or a previously generated temporary identifier. The key may be stored on or derived by the wireless device. For example, the wireless device derives the key based on Kaiot that is preconfigured on the wireless device.

[0103] At 630 of process 600, the wireless device transmits, to the reader device, a second message relating to the first message, with the second message containing the temporary identifier. This second message may be forwarded to a network function (e.g., 156) . If the first message contains a service request such as an inventory request or a command request, the second message contains a corresponding service response such as an inventory response or a command response. In embodiments where the first message contains a temporary identifier update request, the second message contains an updated temporary identifier of the wireless device. In embodiments where the first message contains a temporary identifier update indicator or synchronization indicator, the second message contains an updated temporary identifier or a synchronized temporary identifier of the wireless device.

[0104] In various embodiments, the wireless device includes an Ambient Internet of Things (AIoT) device. The network function may be an ambient internet-of-things function (AIoTF) . In some embodiments, the reader device includes a user equipment (UE) , or a base station.

[0105] Figure 7 shows a flowchart illustrating an example process 700 for wireless communication performed by a network function according to some embodiments.

[0106] At 710 of process 700, a network function (e.g., 156) transmits a first message to a reader device (e.g., 154) . The reader device may be a user equipment or a base station.

[0107] The first message may include or relate to a request (e.g., a service request, an update request, a synchronization request) with respect to one or more wireless devices (e.g., 152) . Accordingly, the first message may be a service request message, a temporary identifier update request message, or a message containing a temporary identifier update indicator or a temporary identifier synchronization indicator. This message may include a permanent device identifier of a wireless device, a plurality of permanent device identifiers of multiple wireless devices (including the specific wireless device) , or a group identifier corresponding to a group of wireless devices (including the specific wireless device) . If the first message includes no identifier, the first message may be transmitted by the reader device to all the wireless devices under the reader device. The derivation of a temporary identifier of the wireless device may be performed based on the permanent device identifier or a previously generated temporary identifier stored on the wireless device.

[0108] In some embodiments, the first message contains or relates to a service request associated with the wireless device, such as an inventory request or a command request. The service request may be provided by a second network function, e.g., an application function (AF) (e.g., 158) , to the network function. The first message may include a freshness parameter, such as a random number or a time stamp. See, e.g., Figure 2 and the description thereof.

[0109] In other embodiments, the first message may contain a temporary identifier update request that includes a freshness parameter, such as a random number or a time stamp. This update request may be initiated by either the network function itself or the reader device, with the freshness parameter being generated by the component that initiates the update request. For example, when a temporary identifier update is initiated by the reader device, the reader device generates the freshness parameter. As anther example, a temporary identifier update is initiated by the network function, the network function generates the freshness parameter. See, e.g., Figures 3 and 4 and the description thereof.

[0110] In some implementations, when utilizing a counter-based approach, the first message may contain omit the freshness parameter. The first message may include a service request, an update indicator, or a synchronization indicator. The counter value for temporary identifier generation, updating, or synchronization, may be determined based on one or more pre-configured counter parameters, including at least one of an initial counter value (COUNT) and a counter increment value (N) . See, e.g., Figure 5 and the description thereof.

[0111] At 720 of process 700, the network function may derive a first temporary identifier of the wireless device using a cryptographic function based on an identifier of the wireless device and a freshness parameter. For example, the network function uses an identifier of the wireless device and a freshness parameter in deriving a temporary identifier (an initial one, an updated one) , the network function includes these parameters in the first message and transmit it to the wireless device, e.g., via the reader device.

[0112] At 730 of process 700, the network function receives, from the reader device, a second message relating to the first message. The second message contains a temporary identifier of the wireless device derived by the wireless device. The derivation may be based on the same cryptographic function and the same input (including the identifier of the wireless device and the freshness parameter) as the derivation by the network function at 720.

[0113] The cryptographic function applied in 720 and 730 may include a hash-based message authentication code (HMAC) function using a key, and the derivation process involves applying inputs including at least one of the freshness parameter, the identifier of the wireless device, or a key. The identifier of the wireless device may be a permanent device identifier or a previously generated temporary identifier. The key may include Ks. The network function may obtain Ks from ADM. The wireless device may derive Ks based on Kaiot that is pre-configured in the wireless device.

[0114] If the first message contained a service request such as an inventory request or a command request, the second message contains a corresponding service response such as an inventory response or a command response. In embodiments where the first message contained a temporary identifier update request, the second message contains an updated temporary identifier of the wireless device. In embodiments where the first message contained a temporary identifier update indicator or synchronization indicator, the second message contains an updated temporary identifier or a synchronized temporary identifier of the wireless device, respectively.

[0115] In some embodiments, the network function verifies whether the second temporary identifier received from the wireless device matches the first temporary identifier derived by the network function for the same wireless device (corresponding to a same identifier of the wireless device) . The network function stores the first or second temporary identified if the network function confirms that the first temporary identifier matches the second temporary identifier for the same wireless device. In some embodiments, the first message may be transmitted to multiple wireless devices, and at least some wireless devices respond by providing a temporary identifier. The network function may store only the received ones, which may be a sub-group of those derived by the network function.

[0116] In various embodiments, the wireless device includes an Ambient Internet of Things (AIoT) device, and the network function may be an ambient internet-of-things function (AIoTF) . The network function may receive a third message from a second network function (e.g., AF 158) , wherein the third message contains at least one of a service request, a permanent device identifier, a plurality of permanent device identifiers, or a group identifier corresponding to a group of wireless devices.

[0117] Figure 8 shows a flowchart illustrating an example process 800 for wireless communication performed by a reader device according to some embodiments.

[0118] At 810 of process 800, a reader device (e.g., 154) transmits a first message to a wireless device (e.g., 152) . The reader device may be a user equipment or a base station that serves as an intermediary between the wireless device and a network function (e.g., 156) .

[0119] The first message may be a service request message, a temporary identifier update request message, or a message containing a temporary identifier update indicator or a temporary identifier synchronization indicator. This message may include a permanent device identifier of the wireless device, a plurality of permanent device identifiers of multiple wireless devices, or a group identifier corresponding to a group of wireless devices. If the first message includes no identifier, the first message may be transmitted by the reader device to all the wireless devices under the reader device. The derivation of a temporary identifier of the wireless device may be performed based on the permanent device identifier or a previously generated temporary identifier stored on the wireless device. The reader device may receive the first message from the network function and forward it to the wireless device.

[0120] In some embodiments, the first message forwarded by the reader device contains a service request associated with the wireless device, such as an inventory request or a command request. The service request may include parameters such as a freshness parameter, a device identifier of the wireless device, or a group identifier of a group of AIoT devices. See, e.g., Figure 2 and the description thereof.

[0121] In other embodiments, the first message may contain a temporary identifier update request that includes a freshness parameter, such as a random number or a time stamp. This update request may be initiated by either the network function or the reader device itself. For example, when a temporary identifier update is initiated by the reader device, the reader device generates the freshness parameter. As anther example, a temporary identifier update is initiated by the network function, the network function generates the freshness parameter. See, e.g., Figures 3 and 4 and the description thereof.

[0122] In some implementations with a counter-based approach, the first message may omit the freshness parameter. The first message may include a service request, an update indicator, or a synchronization indicator. The counter value for temporary identifier generation, updating, or synchronization, may be determined based on one or more pre-configured counter parameters, including at least one of an initial counter value (COUNT) and a counter increment value (N) . See, e.g., Figure 5 and the description thereof.

[0123] At 820 of process 800, the reader device transmits, to a network function (e.g., AIoTF 156) , a second message relating to the first message. The second message contains a temporary identifier of the wireless device derived by the wireless device using a cryptographic function based on an identifier of the wireless device and the freshness parameter. The reader device receives this temporary identifier from the wireless device in response to the first message and forwards it to the network function. The identifier of the wireless device

[0124] If the first message contained a service request such as an inventory request or a command request, the second message contains a corresponding service response such as an inventory response or a command response that includes the temporary identifier. In embodiments where the first message contained a temporary identifier update request, the second message contains an updated temporary identifier of the wireless device. In embodiments where the first message contained a temporary identifier update indicator or synchronization indicator, the second message contains an updated temporary identifier or a synchronized temporary identifier of the wireless device, respectively.

[0125] In various embodiments, the wireless device comprises an Ambient Internet of Things (AIoT) device, and the network function may be an ambient internet-of-things function (AIoTF) .

[0126] Processes 600, 700, and 800, working in conjunction, implement a communication chain for privacy protection in AIoT systems. The reader device serves as an intermediary that enables secure communication between AIoT devices and network functions while helping maintain privacy through the use of temporary identifiers instead of permanent device identifiers.

[0127] The technical architecture and methods illustrated in Figures 2-8 provide several significant benefits for AIoT device communications. First, they enhance privacy protection by preventing unauthorized tracking and monitoring of AIoT devices, as attackers cannot correlate communications to specific devices when temporary identifiers are regularly updated. Second, the system provides flexibility by supporting multiple update mechanisms (network-initiated, reader-initiated, and counter-based approaches) , allowing deployment in various network configurations. Third, the counter-based approach with synchronization capabilities (Figure 5) ensures robustness against communication failures by providing a recovery mechanism when temporary identifiers become desynchronized. Fourth, the solution maintains backward compatibility with existing AIoT service operations while adding privacy protection. Finally, the distributed derivation of identical temporary identifiers by both the device and network sides reduces or eliminates the need to transmit sensitive identifiers, significantly reducing vulnerability to eavesdropping attacks.

[0128] Example technical solutions implemented by preferred embodiments

[0129] Solution 1. A method for wireless communication (process 600 in Figure 6) , comprising: receiving, by a wireless device from a reader device, a first message; obtaining a temporary identifier of the wireless device by deriving, by the wireless device, the temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; and transmitting, by the wireless device to the reader device, a second message relating to the first message, the second message containing the temporary identifier.

[0130] Solution 2. A method for wireless communication (e.g., process 700 depicted in Figure 7) , comprising: transmitting, by a network function to a reader device, a first message relating to a wireless device; obtaining a first temporary identifier of the wireless device by deriving, by the network function, the first temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; and receiving, from the reader device, a second message relating to the first message, the second message containing a second temporary identifier of the wireless device derived by the wireless device using the cryptographic function based on the identifier of the wireless device and the freshness parameter.

[0131] Solution 3. A method for wireless communication (e.g., process 800 depicted in Figure 8) , comprising: transmitting, by a reader device to a wireless device, a first message; and transmitting, by the reader device to a network function, a second message relating to the first message, the second message containing a temporary identifier of the wireless device derived by the wireless device using a cryptographic function based on an identifier of the wireless device and a freshness parameter.

[0132] Solution 4. The method of one or more of solutions disclosed herein, wherein the reader device is a user equipment.

[0133] Solution 5. The method of one or more of any one of solution 2 or other solutions disclosed herein, comprising: storing the first or second temporary identifier of the wireless device.

[0134] Solution 6. The method of one or more of solutions disclosed herein, wherein the freshness parameter comprises at least one of a random number, a time stamp, or a counter value.

[0135] Solution 7. The method of one or more of any one of solution 6 or other solutions disclosed herein, wherein the freshness parameter is generated by the network function or determined by the wireless device based on a pre-configured counter parameter.

[0136] Solution 8. The method of one or more of any one of solution 7 or other solutions disclosed herein, wherein the counter parameter comprises at least one of an initial counter value (COUNT) and a counter increment value (N) .

[0137] Solution 9. The method of one or more of solutions disclosed herein, wherein the wireless device comprises an Ambient Internet of Things (AIoT) device.

[0138] Solution 10. The method of one or more of solutions disclosed herein, wherein the network function is an ambient internet-of-things function (AIoTF) .

[0139] Solution 11. The method of one or more of solutions disclosed herein, wherein the first message contains a service request associated with the wireless device, and corresponding the second message contains a service response by the wireless device.

[0140] Solution 12. The method of one or more of any one of solution 11 or other solutions disclosed herein, wherein the service request comprises an inventory request or a command request, and correspondingly the service response comprises an inventory response or a command response.

[0141] Solution 13. The method of one or more of any one of solution 11 or other solutions disclosed herein, wherein the service request includes at least one of following parameters: the freshness parameter, a counter parameter, a device identifier of the wireless device, a group identifier of a group of AIoT devices.

[0142] Solution 14. The method of one or more of solutions disclosed herein, wherein the first message contains a temporary identifier update request that contains the freshness parameter, and the second message contains an updated temporary identifier of the wireless device.

[0143] Solution 15. The method of one or more of any one of solution 14 or other solutions disclosed herein, wherein the temporary identifier update request is initiated by the network function or the reader device.

[0144] Solution 16. The method of one or more of any one of solution 15 or other solutions disclosed herein, wherein, the temporary identifier update request is initiated by the network function, and the freshness parameter is generated by the network function.

[0145] Solution 17. The method of one or more of any one of solution 15 or other solutions disclosed herein, wherein, the temporary identifier update request is initiated by the reader device, and the freshness parameter is generated by the reader device

[0146] Solution 18. The method of claim 16 or claim 17, wherein the freshness parameter comprises a random number or a time stamp.

[0147] Solution 19. The method of one or more of solutions disclosed herein, wherein the freshness parameter is a counter value, the first message contains an update indicator or a synchronization indicator.

[0148] Solution 20. The method of one or more of any one of solution 19 or other solutions disclosed herein, wherein based on the update indicator, the wireless device derives an updated temporary identifier using a counter value. In some embodiments, the counter value is determined by the wireless device based on one or more counter parameters pre-configured on the wireless device.

[0149] Solution 21. The method of one or more of any one of solution 19 or other solutions disclosed herein, wherein based on the synchronization indicator, the wireless device derives a synchronized temporary identifier using a pre-configured counter value.

[0150] Solution 22. The method of one or more of solutions disclosed herein, wherein the function comprises a hash-based message authentication code (HMAC) function using an input key.

[0151] Solution 23. The method of one or more of solutions disclosed herein, wherein deriving, by the wireless device, the temporary identifier comprises applying input to the cryptographic function, the input comprises at least one of the freshness parameter, the identifier of the wireless device, or a key.

[0152] Solution 24. The method of one or more of any one of solution 2 or other solutions disclosed herein, wherein deriving, by the network function, the first temporary identifier comprises applying input to the cryptographic function, the input comprising at least one of the freshness parameter, the identifier of the wireless device, or a key.

[0153] Solution 25. The method of one or more of any one of solution 23 or 24, or other solutions disclosed herein, wherein the identifier of the wireless device is a permanent device identifier or a previously generated temporary identifier.

[0154] Solution 26. The method of solutions disclosed herein, wherein the network function receives, from a second network function, a third message that corresponds to the first message, and wherein the third message contains at least one of a service request, a permanent device identifier, a plurality of permanent device identifiers, or a group identifier corresponding to a group of wireless devices.

[0155] Solution 27. A method for wireless communication, comprising: transmitting, by a first network function to a second network function, a service request relating to a wireless device with at least one parameter for determining a freshness parameter. In some embodiments, the freshness parameter includes a counter value. In some embodiments, the at least one parameter includes one or more counter parameters, such as an initial counter value (COUNT) and a counter increment value (N) . The at least one parameter for determining the freshness parameter may be pre-configured on the first network function, e.g., AF 158. The second network function may be AIoTF 156. The service request may be an inventory request or a command request. The service request may be transmitted, by the first network function to the second network function, with identifier information relating to the wireless device. The identifier information may include a device identifier of the wireless device, a device identifier list, or a group identifier corresponding to a group of wireless devices.

[0156] Solution 28. A communication apparatus comprising at least one processor configured to cause the communication apparatus to implement a method recited in any one or more of solutions 1-27.

[0157] Solution 29. At least one computer-readable medium having code stored thereon, the code, upon execution by at least one processor of an apparatus, causing the apparatus to implement any one or more of solutions 1-27.

[0158] Figure 9 shows an example of a wireless communication system (e.g., a long term evolution (LTE) , 5G or NR cellular network) that includes a base station BS 120 and one or more user equipment (UE) 111, 112 and 113. In some embodiments, the uplink transmissions (131, 132, 133) can include uplink control information (UCI) , higher layer signaling (e.g., UE assistance information or UE capability) , or uplink information. In some embodiments, the downlink transmissions (141, 142, 143) can include downlink control information, DCI or medium access control (MAC) information or high layer signaling or downlink information. The UE may be, for example, a smartphone, a tablet, a mobile computer, a machine to machine (M2M) device, a terminal, a mobile device, an Internet of Things (IoT) device, and so on. Various core network functions depicted in Figure 9 may be communicatively coupled (directly or indirectly) to the BS 120.

[0159] Figure 10 is a block diagram representation of a portion of an apparatus, in accordance with some embodiments of the presently disclosed technology. An apparatus 1005 such as a network device or a base station or a wireless device (or UE) , can include processor electronics 1010 such as one or more processors, one or more microprocessors, or the like, which implements one or more of the techniques presented in this document. The apparatus 1005 can include transceiver electronics 1015 to send or transmit and / or receive signals and messages over one or more communication interfaces such as antenna (s) 1020 or a wired interface (not explicitly shown) . The apparatus 1005 can include other communication interfaces for transmitting and receiving data. Apparatus 1005 can include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some implementations, the processor electronics 1010 can include at least a portion of the transceiver electronics 1015. In some embodiments, at least some of the disclosed techniques, actors (refer to Figures 2 to 5) modules or functions are implemented using the apparatus 1005.

[0160] It will be appreciated that the present document discloses at least the following techniques.

[0161] It will be appreciated that the above-disclosed techniques are useful in making AIoT service request / response tasks more robust to unauthorized access to the information stored in AIoT devices. In one aspect, authentication of a service request is performed such that the AIoT device discards a service request upon not being able to authorize the service request from its previously stored information about a reader ID with which the AIoT device had previously communicated in an authenticated manner.

[0162] Some of the embodiments described herein are described in the general context of methods or processes, which may be implemented in one embodiment by a computer program product, embodied in a computer-readable medium, including computer-executable instructions, such as program code, executed by computers in networked environments. A computer-readable medium may include removable and non-removable storage devices including, but not limited to, Read Only Memory (ROM) , Random Access Memory (RAM) , compact discs (CDs) , digital versatile discs (DVD) , etc. Therefore, the computer-readable media can include a non-transitory storage media. Generally, program modules may include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer-or processor-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represents examples of corresponding acts for implementing the functions described in such steps or processes.

[0163] Some of the disclosed embodiments can be implemented as devices or modules using hardware circuits, software, or combinations thereof. For example, a hardware circuit implementation can include discrete analog and / or digital components that are, for example, integrated as part of a printed circuit board. Alternatively, or additionally, the disclosed components or modules can be implemented as an Application Specific Integrated Circuit (ASIC) and / or as a Field Programmable Gate Array (FPGA) device. Some implementations may additionally or alternatively include a digital signal processor (DSP) that is a specialized microprocessor with an architecture optimized for the operational needs of digital signal processing associated with the disclosed functionalities of this application. Similarly, the various components or sub-components within each module may be implemented in software, hardware or firmware. The connectivity between the modules and / or components within the modules may be provided using any one of the connectivity methods and media that is known in the art, including, but not limited to, communications over the Internet, wired, or wireless networks using the appropriate protocols.

[0164] While this document contains many specifics, these should not be construed as limitations on the scope of an invention that is claimed or of what may be claimed, but rather as descriptions of features specific to particular embodiments. Certain features that are described in this document in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or a variation of a sub-combination. Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results.

[0165] Only a few implementations and examples are described, and other implementations, enhancements, and variations can be made based on what is described and illustrated in this document.

Claims

1.A method for wireless communication, comprising:receiving, by a wireless device from a reader device, a first message;obtaining a temporary identifier of the wireless device by deriving, by the wireless device, the temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; andtransmitting, by the wireless device to the reader device, a second message relating to the first message, the second message containing the temporary identifier.2.A method for wireless communication, comprising:transmitting, by a network function to a reader device, a first message relating to a wireless device;obtaining a first temporary identifier of the wireless device by deriving, by the network function, the first temporary identifier using a cryptographic function based on an identifier of the wireless device and a freshness parameter; andreceiving, from the reader device, a second message relating to the first message, the second message containing a second temporary identifier of the wireless device derived by the wireless device using the cryptographic function based on the identifier of the wireless device and the freshness parameter.3.A method for wireless communication, comprising:transmitting, by a reader device to a wireless device, a first message; andtransmitting, by the reader device to a network function, a second message relating to the first message, the second message containing a temporary identifier of the wireless device derived by the wireless device using a cryptographic function based on an identifier of the wireless device and a freshness parameter.4.The method of any one of claims 1-3, wherein the reader device is a user equipment.5.The method of claim 2, comprising: storing the first or second temporary identifier of the wireless device.6.The method of any one of claims 1-3, wherein the freshness parameter comprises at least one of a random number, a time stamp, or a counter value.7.The method of claim 6, wherein the freshness parameter is generated by the network function or determined by the wireless device based on a pre-configured counter parameter.8.The method of claim 7, wherein the counter parameter comprises at least one of an initial counter value (COUNT) and a counter increment value (N) .9.The method of any one of claims 1-3, wherein the wireless device comprises an Ambient Internet of Things (AIoT) device.10.The method of any one of claims 1-3, wherein the network function is an ambient internet-of-things function (AIoTF) .11.The method of any one of claims 1-3, wherein the first message contains a service request associated with the wireless device, and corresponding the second message contains a service response by the wireless device.12.The method of claim 11, wherein the service request comprises an inventory request or a command request, and correspondingly the service response comprises an inventory response or a command response.13.The method of any of claim 11, wherein the service request includes at least one of following parameters: the freshness parameter, a counter parameter, a device identifier of the wireless device, a device identifier list, or a group identifier of a group of AIoT devices.14.The method of any one of claims 1-3, wherein the first message contains a temporary identifier update request that contains the freshness parameter, and the second message contains an updated temporary identifier of the wireless device.15.The method of claim 14, wherein the temporary identifier update request is initiated by the network function or the reader device.16.The method of claim 15, wherein the temporary identifier update request is initiated by the network function, and the freshness parameter is generated by the network function.17.The method of claim 15, wherein the temporary identifier update request is initiated by the reader device, and the freshness parameter is generated by the reader device.18.The method of claim 16 or claim 17, wherein the freshness parameter comprises a random number or a time stamp.19.The method of any one of claims 1-3, wherein the freshness parameter is a counter value, the first message contains an update indicator or a synchronization indicator.20.The method of claim 19, wherein based on the update indicator, the wireless device derives an updated temporary identifier using a counter value, and wherein the counter value is determined by the wireless device based on one or more counter parameters pre-configured on the wireless device.21.The method of claim 19, wherein based on the synchronization indicator, the wireless device derives a synchronized temporary identifier using a pre-configured counter value.22.The method of any one of claims 1-3, wherein the function comprises a hash-based message authentication code (HMAC) function using an input key.23.The method of any one of claims 1-3, wherein deriving, by the wireless device, the temporary identifier comprises applying input to the cryptographic function, the input comprising at least one of the freshness parameter, the identifier of the wireless device, or a key.24.The method of claim 2, wherein deriving, by the network function, the first temporary identifier comprises applying input to the cryptographic function, the input comprising at least one of the freshness parameter, the identifier of the wireless device, or a key.25.The method of claim 23 or claim 24, wherein the identifier of the wireless device is a permanent device identifier or a previously generated temporary identifier.26.The method of any one of claims 1-3, wherein the first message corresponds to a third message that the network function receives from a second network function, and wherein the third message contains at least one of a service request, a permanent device identifier, a plurality of permanent device identifiers, or a group identifier corresponding to a group of wireless devices.27.A communication apparatus comprising at least one processor configured to cause the communication apparatus to implement a method recited in any one or more of claims 1-26.28.At least one computer-readable medium having code stored thereon, the code, upon execution by at least one processor of an apparatus, causing the apparatus to implement any one or more of claims 1-26.

Images