Data protection of ambient internet of things (IOT) devices

Abstract

The present disclosure relates to protecting at least an identifier of an ambient IoT device. The identifier can be exchanged between the ambient IoT device and a network node of a network. The identifier can be protected and verified in the data exchange such that it may not be compromised by an unauthorized device or, if compromised, used by the unauthorized device. Different identifier protection procedures can be used, including the use of a hashing function and a parameter, an encryption function, and / or a limited number of use or limited time duration identifier.

Description

DATA PROTECTION OF AMBIENT INTERNET OF THINGS (IOT) DEVICESTECHNICAL FIELD

[0001] The present disclosure generally relates to wireless communication, and in particular, to data protection of ambient internet of things (IOT) devices.BACKGROUND

[0002] Cellular communications can be defined in various standards to enable communications between a user equipment and a cellular network. For example, Fifth Generation mobile network (5G) is a wireless standard that aims to improve upon data transmission speed, reliability, availability, power consumption, and more. In such a network, ambient Internet of Things (IoT) devices can be deployed. Generally, an ambient IoT device has limited capabilities and can send data upon request from the network.BRIEF DESCRIPTION OF THE DRAWINGS

[0003] FIG. 1 illustrates a network environment, in accordance with various embodiments.

[0004] FIG. 2 illustrates an example of a sequence diagram for a data exchange involving an ambient Internet of Things (IoT) device, in accordance with various embodiments.

[0005] FIG. 3 illustrates an example of a sequence diagram for data protection of an ambient IoT device involving a hashing function, in accordance with various embodiments.

[0006] FIG. 4 illustrates another example of a sequence diagram for data protection of an ambient IoT device involving a hashing function, in accordance with various embodiments.

[0007] FIG. 5 illustrates yet an example of a sequence diagram for data protection of an ambient IoT device involving a hashing function, in accordance with various embodiments, in accordance with various embodiments.

[0008] FIG. 6 illustrates an example of a sequence diagram for data protection of an ambient IoT device involving an encryption function, in accordance with various embodiments.

[0009] FIG. 7 illustrates another example of a sequence diagram for data protection of an ambient IoT device involving an encryption function, in accordance with various embodiments.

[0010] FIG. 8 illustrates an example of a sequence diagram for data protection of an ambient IoT device involving a one-time identifier, in accordance with various embodiments.

[0011] FIG. 9 illustrates another example of a sequence diagram for data protection of an ambient IoT device involving a one-time identifier, in accordance with various embodiments.

[0012] FIG. 10 illustrates an example of an operational flow / algorithmic structure implemented by an ambient IoT device in support of data protection, in accordance with various embodiments.

[0013] FIG. 11 illustrates an example of an operational flow / algorithmic structure implemented by a reader in support of data protection, in accordance with various embodiments.

[0014] FIG. 12 illustrates an ambient IoT device, in accordance with some embodiments.

[0015] FIG. 13 illustrates a reader, in accordance with some embodiments.DETAILED DESCRIPTION

[0016] The present disclosure relates to, among other things, protection of a data exchange between a network and a device. In an example, the device is an ambient Internet of Things (IoT) device. The network may be a cellular network that complies with technical specifications (e.g., 3GPP technical specifications, where the cellular network can be a fifth generation new radio, or subsequent generation, cellular network) . The ambient IoT device can also comply with the technical specifications and have limited capabilities related to its power source, processing, data storage, and / or reception and transmission. In this example, the data exchange can include the network transmitting an identifier associated with the IoT device (e.g., in a paging message) and / or the IoT device transmitting the identifier to the network (e.g., in a random access message and / or in an uplink data transmission) . The protection can involve protecting the identifier according to an identifier protection technique such that the identifier cannot be determined by an unauthorized device or, if determined, it cannot be used.

[0017] Different identifier protection techniques can be used (individually or in combination) . In one example technique, a parameter is used and can be pre-shared between the network and the ambient IoT device or can be selected (e.g., randomly) by one of the network or the ambient IoT device and then shared with the other one of the network or the ambient IoT device. In this example technique, the identifier can be hashed in any exchange between the network and the ambient IoT device and the value of the parameter can be used to compute the hash and / or in a verification process of the protected identifier. In another example technique, an encryption can be used to encrypt at least the identifier. Here, the use of hashing or a clear portion of the identifier (e.g., the three least significant bits (LSBs) may be sent without encryption or hashing) can also be implemented to assist in the verification of the protected identifier. In yet another technique, a limited-use identifier (e.g., a one-time identifier) is used. Here, the identifier can be used up to a certain number of times (e.g., one time) or within a limited time duration (e.g., after which it expires) . These and other techniques are further described herein below.

[0018] By protecting the identifier, many technical advantages can be achieved. For instance, the security of the data exchange can be improved by protecting against the identifier being accessible or used by an unauthorized device. Further, the protection is secure enough while also not necessitating a complex scheme that would not be possible to implemented on an ambient IoT device given its limited capabilities.

[0019] In the interest of clarity of explanation, the various embodiments are described in connection with an ambient IoT device that uses cellular communications compliant with the 3GPP technical specifications. However, the embodiments are not limited as such and can apply to other types of devices and / or possibly to other wireless communications.

[0020] The following detailed description refers to the accompanying drawings. The same reference numbers may be used in different drawings to identify the same or similar elements. In the following description, for purposes of explanation and not limitation, specific details are set forth such as particular structures, architectures, interfaces, techniques, etc. in order to provide a thorough understanding of the various aspects of various embodiments. However, it will be apparent to those skilled in the art having the benefit of the present disclosure that the various aspects of the various embodiments may be practiced in other examples that depart from these specific details. In certain instances, descriptions of well-known devices, circuits, and methods are omitted so as not to obscure the description of  the various embodiments with unnecessary detail. For the purposes of the present document, the phrase “Aor B” means (A) , (B) , or (Aand B) ; and the phrase “based on A” means “based at least in part on A, ” for example, it could be “based solely on A” or it could be “based in part on A. ”

[0021] The following is a glossary of terms that may be used in this disclosure.

[0022] The term “circuitry” as used herein refers to, is part of, or includes hardware components such as an electronic circuit, a logic circuit, a processor (shared, dedicated, or group) or memory (shared, dedicated, or group) , an application specific integrated circuit (ASIC) , a field-programmable device (FPD) (e.g., a field-programmable gate array (FPGA) , a programmable logic device (PLD) , a complex PLD (CPLD) , a high-capacity PLD (HCPLD) , a structured ASIC, or a programmable system-on-a-chip (SoC) ) , digital signal processors (DSPs) , etc., that are configured to provide the described functionality. In some embodiments, the circuitry may execute one or more software or firmware programs to provide at least some of the described functionality. The term “circuitry” may also refer to a combination of one or more hardware elements (or a combination of circuits used in an electrical or electronic system) with the program code used to carry out the functionality of that program code. In these embodiments, the combination of hardware elements and program code may be referred to as a particular type of circuitry.

[0023] The term “processor circuitry” as used herein refers to, is part of, or includes circuitry capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, or recording, storing, or transferring digital data. The term “processor circuitry” may refer an application processor, baseband processor, a central processing unit (CPU) , a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions, such as program code, software modules, or functional processes.

[0024] The term “device” as used herein refers to a device with radio communication capabilities and may describe a remote user of network resources in a communications network. The term “device” may be considered synonymous to, and may be referred to as, a user equipment (UE) such as a client, mobile, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, reconfigurable mobile  device, etc. Furthermore, the term “user equipment” or “UE” may include any type of wireless / wired device or any computing device including a wireless communications interface.

[0025] The term “base station” as used herein refers to a device with radio communication capabilities, that is a network component of a communications network (or, more briefly, a network) , and that may be configured as an access node in the communications network. A UE’s access to the communications network may be managed at least in part by the base station, whereby the UE connects with the base station to access the communications network. Depending on the radio access technology (RAT) , the base station can be referred to as a gNodeB (gNB) , eNodeB (eNB) , access point, etc.

[0026] The term “network” as used herein reference to a communications network that includes a set of network nodes configured to provide communications functions to a plurality of user equipment via one or more base stations. For instance, the network can be a public land mobile network (PLMN) that implements one or more communication technologies including, for instance, 5G communications.

[0027] The term “based on” as used herein may indicate that an item is based solely on another item and / or an item is based on another item and one or more additional items. For example, item 1 being determined based on item 2 may indicate that item 1 is determined based solely on item 2 and / or is determined based on item 2 and one or more other items in embodiments.

[0028] FIG. 1 illustrates a network environment, in accordance with some embodiments. The network environment may include an ambient IoT device 110 (also referred to as AIoT device) communicatively coupled with a base station reader 120. The base station reader 120 can be a network node of a network, whereby the network node is configured to provide access to the network, and whereby the network can be a cellular network that includes a core network 125. The ambient IoT device 110 and the base station reader 120 may communicate over air interfaces compatible with 3GPP technical specifications (TSs) and technical requirements (TRs) such as those that define a Fifth Generation (5G) new radio (NR) system or a later system. Similarly, the base station reader 120 and the core network 125 may communicate over interfaces compatible with the 3GPP TSs.

[0029] In an example, the ambient IoT device 110 has limited capabilities with respect to at least one of: power storage, processing, memory storage, and / or reception and transmission. In one particular illustration, the ambient IoT device 110 is an IoT device powered by energy harvesting, with limited energy storage capability, as defined in 3GGP TR 23.700-13 (all applicable versions) , the content of which is incorporated herein in its entirety by reference. Other characteristics of the ambient IoT device 110 can also be defined in 3GPP TR 38.769 (all applicable versions) , the content of which is also incorporated herein in its entirety by reference. For instance, the ambient IoT device 110 can be a sensor, with an energy harvesting source (e.g., a solar panel) that collects data and responds to commands for sending the data.

[0030] The base station reader 120 can be a gNB, a transmission and reception point (TRP) , a radio frequency reader, an access point, or any other network node supports an air interface with the ambient IoT device 110 according to the 3GPP TSs and TRs. The base station reader 120 can be responsible to manage a plurality of ambient IoT devices 110, each of which can be similar to or can have a different function than the ambient IoT device 110. The base station reader 120 and such ambient IoT devices can belong to a same network of an operator (e.g., a private network) , whereas the core network 125 may, but need not, be provided by a different service provider.

[0031] The core network 125 may comprise a 5th Generation Core network (5GCN) or later generation core network. The core network 125 may be coupled to the base station reader 120 via a fiber optic or a wireless backhaul. The core network 125 may provide functions for the ambient IoT device 110 via the base station reader 120. These functions may include different functions, a core access and mobility management function (AMF) , a session management function (SMF) , an application function (AF) , etc. The functions may also include communicatively coupling devices, such as the ambient IoT device 110, to one or more external data networks that may be cellular networks and non-cellular networks.

[0032] As further described herein below, a protected data exchange 150 can occur between the ambient IoT device 110 and the base station reader 120. The protected data exchange can involve the base station reader 120 sending one or more messages to the ambient IoT device 110 on a downlink channel and the ambient IoT device 100 sending one or more messages to the base station reader 120 on an uplink channel. Such messages can include an identifier of the ambient IoT device 110. The protected data exchange 150  signifies that the identifier is protected in the messages such that the identifier cannot be determined by an unauthorized device from the protected data exchange 150 (e.g., a device other than the base station reader 120 or the ambient IoT device 110) or, if determined, cannot be used by the unauthorized device.

[0033] The identifier can be protected by using an identifier protection procedure 130 implemented at the ambient IoT device 110 and / or an identifier protection procedure 140 implemented at the base station reader 120. The two identifier protection procedures 130 and 140 are further described in the next figures. Generally, the identifier protection procedure 130 can involve any or a combination of using a hashing function 132, an encryption function 134, and / or an indexing function 136. Each of these three functions can used protection data 138 stored in a memory of the ambient IoT ambient device 110. Examples of protection data includes one or more identifiers, shared parameters, encryption keys, and the like. Similarly, the identifier protection procedure 140 can involve any or a combination of using a hashing function 142, an encryption function 144, and / or an indexing function 146. Each of these three functions can use protection data 148 stored in a memory of the base station reader 120. Examples of protection data includes one or more identifiers, shared parameters, encryption keys, and the like. Generally, if both identifier protection procedure 130 and identifier protection procedure 140 are implemented, the same functions would be used (e.g., if the hashing function 132 is used, the hashing function 142 is also used; if the encryption function 144 is used (e.g., to encrypt an identifier) , the encryption function 134 is also used (e.g., to decrypt the identifier) ) .

[0034] A 3GPP study on ambient IoT focuses on providing clear differentiation related to use cases and scenarios that cannot otherwise be fulfilled based on existing 3GPP low-power wide-area (LWPA) IoT. Studying the potential threats, security requirements to address the potential threats, and security solutions to support ambient IoT services is needed. Particularly, potential threats and security requirements need to be identified to enable ambient IoT services for various use cases including the ones defined in 3GPP TS 22.369 (all versions) , for topologies captured in 3GPP RP-234058, and for architecture captured in 3GPP TR 23-700-13 (all versions) , the contents of which are herein incorporated by reference in their entirety.

[0035] An ambient IoT service is a type of cellular IoT communication system where ambient IoT devices utilize harvested energy to generate RF signals for bi-directional  information transmission. Ambient IoT devices are characterized by limited functions, necessitating only small and infrequent data transfers. 3GPP TS 22.369 defines the following privacy-related requirements: “The 5G system shall be able to provide a mechanism to protect the privacy of information (e.g., location and identity) exchanged during communication between an Ambient IoT device and the 5G network or an Ambient IoT capable UE. In AIoT services, identifiers of an AIoT device are used to identify the device. If the identifiers associated with a device are not privacy protected (e.g., exposed over the air) , an attacker (e.g., an over-the-air attacker) can identify and track an AIoT device based on the identifiers associated with the AIoT device. As far as security threats, an attacker can identify, monitor and track an AIoT device based on the identifiers associated with the AIoT device if the identifiers are not privacy protected. Thus, mechanisms need to be developed to privacy protect the AIoT device identifiers and to mitigate privacy threats by identifying, linking, and tracking the identifiers of AIoT device (s) . The identifier protection procedures 130 and 140 provide such mechanisms and assume that the ambient IoT device 110 is capable (e.g., has sufficient processing and memory space to execute related functionalities and / or or implement such functionalities in hardware) of supporting the identifier protection procedure 130.

[0036] FIG. 2 illustrates an example of a sequence diagram for a data exchange involving an ambient IoT device 210, in accordance with various embodiments. The ambient IoT device 210 is an example of the ambient IoT device 110 of FIG. 1. The sequence diagram can also involve a base station reader 220 (an example of the base station 120) and a core network 225 (an example of the core network 125) .

[0037] Generally, the sequence diagram includes three steps: paging, access, and data transmission. The paging can involve the exchange of messages, such as a paging message that the base station reader 220 transmits (e.g., broadcasts) . The paging message can include an identifier associated with the ambient IoT device 210. The access can involve a transmission of the identifier according to, for example, a random access (RACH) procedure (similar to a RACH procedure defined in 3GPP TSs for a conventional UE) . In one example, the RACH procedure can be a two-step RACH procedure where the ambient IoT device 210 sends the identifier in a RACH message (e.g. a message three (Msg3) ) to the base station reader 220. The data transmission can involve uplink and downlink data transmissions according to one or more commands of the base station reader 220.

[0038] Specific to the paging step, the core network 225 can send a service request to the base station reader 220. In turn, the base station reader 220 can send a paging-like or initial message to the ambient IoT device 210. This message can be referred to as a paging message (or an AIoT paging message) . Different possible pieces of content can be included in the paging message. For example, the paging message can include any or a combination of an identifier of a single ambient IoT device (where this identifier can be pre-stored by the ambient IoT device) , a group identifier that maps to multiple ambient IoT devices (where this identifier can also be pre-stored by the ambient IoT device) , and / or multiple identifies of different ambient IoT devices (where each of such devices can pre-store one or more of such identifiers) . Alternatively, the paging message may not contain an identifier, in which case this message can be considered to be addressed to all devices that can receive it. The paging message can also indicate information from which the ambient IoT device 210 can determine resources to be used for a response. It can be assumed that the ambient IoT device 210 can receive the paging message as long as there is enough energy.

[0039] Herein next and in the figures below, a protection of an identifier is described. The identifier can be the single identifier specific to the ambient IoT device 210, the group identifier, or any of the identifiers of the multiple identifiers included in the paging message.

[0040] Specific to the access step, a random access procedure can be implemented. Per this procedure, the ambient IoT device 210 can send a message-one (Msg1 or AIoT Msg1) to the base station reader 220. This message can include a randomly generated identifier by device (which may need not be protected) . In a message-two (Msg2) , the base station 220 echoes the identifier received in the message-one. Here also, this message or identifier therein need not be protected. The ambient IoT device 210 considers the contention resolution as successful, if the Msg2 including the same random identifier in Msg1 is received. Next, the ambient IoT device 210 sends an identifier and / or any other upper layer data (depending on an upper layer request) , where at least this identifier needs to be protected (e.g., corresponds to a paged identifier and is pre-stored in the memory of the ambient IoT device 210) . At least this identifier (and possibly the data) can be sent in a message-three (Msg3 or AIoT Msg3) . Subsequently, a message-four (Msg4 or AIoT Msg4) may but need not be sent in random access by the ambient IoT device 210. Msg4 can be considered to handle the Msg3 transmission failure (FIG. 3 illustrates an example of a sequence diagram for data protection of an ambient IoT device involving a hashing function, in accordance with various embodiments.

[0041] Specific to the data transmission, some of the uplink data can be sent in Msg3 or Msg4 (or other messages of the random access procedure, where the size of this data can be limited) . Other uplink data can be sent by the ambient IoT device 210 to the base station reader 220 and / or downlink data can be received by the ambient IoT device 210 from the base station reader 210 following a command exchange. The uplink data and / or downlink data can include an identifier that needs protection. Further, the uplink data can be sent from the base station reader 220 to the core network 225 and the downlink data can be received by the base station reader 220 from the core network 225.

[0042] As such, an identifier is pre-stored by the ambient IoT device 210 and / or the base station reader 220. This identifier storage can be part of manufacturing the ambient IoT device 210 or following an over the air (OTA) update of the manufacturing the ambient IoT device 210 and can be part of a configuration of the base station reader 220. The identifier may be exchanged (at least in a paging message and a random access message) . Protection can be applied to as part of the exchange (e.g., at least in the paging procedure and in the random access procedure) . Herein next, this protection is described.

[0043] FIG. 3 illustrates an example of a sequence diagram for data protection of an ambient IoT device 310 involving a hashing function, in accordance with various embodiments. The ambient IoT device 310 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device 310. In addition to the ambient IoT device 310, the sequence diagram involves a reader 320 (e.g., an example of the base station reader 220) , an ambient IoT function (AIoTF) 330, a network exposure function (NEF) 340, and an application function (AF) 350. The AIoTF 330 can be a function implemented in an operator network (e.g., the private network that includes the reader 320 and the ambient IoT device 310, such as by being implemented on the base station) . The NEF 340 and the AF 350 can be implemented in a core network (e.g., the core network 225) .

[0044] In sub-steps of an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection. Particularly, at sub-step “0a, ” the ambient IoT device 310 is configured with a device identifier (e.g., specific to only the ambient IoT device 310 or a group identifier) . The configuration can occur at manufacturing time where this device identifier is stored in a memory of the ambient IoT device 310. At sub-step “0b, ” the AF 350 can send device identifiers (of multiple ambient  IoT devices or groups thereof to be managed by readers including the reader 320) to the AIoTF 330 through the NEF 340. At sub-step “0c, ” the AIoT 330 determines the device identifiers applicable to the reader 320 (of the ambient IoT devices or groups thereof to be managed by the reader 320) and sends these device identifiers to the reader 320. This determination can occur according to a distribution policy received from the AF 350 and / or a local policy from a mobile network operator. At sub-step “0d, ” the reader 320 is configured with the applicable device IDs. For example, the reader 320 stores in its memory the device IDs sent by the AIoTF 330. Further, the reader 330 can derive a random counter “Nx” for each device identifier (e.g., “N1” for “ID1” , “N2” for “ID2” and so on, where each counter “Nx” is a random number and corresponds to a device identifier “x” ) . It is possible that a single random counter “N” (e.g., a single random number) is generated and stored for all device identifiers. In both cases, the reader 320 stores each device identifier, a corresponding random counter, where the storage associates this pair of protected data (e.g., in a mapping) . Further, it may be possible that the reader 320 computes a hash for each pair by using a hashing function (e.g., the hashing function 142 of FIG. 1) . The hashes can be stored in the reader’s 320 memory in association with the corresponding device identifier-random counter pairs (in the mapping) . Pre-computing and storing the hashes can speed up an identifier verification step (further discussed herein below as part of the sequence diagram) .

[0045] In a first step (labeled with numeral “1” ) , the reader 320 can send a paging message to one or more ambient IoT devices that the reader 320 is responsible for. This paging message can be in response to a service request of the core network. In FIG. 3, the paging message relates to multiple ambient IoT devices, including the ambient IoT device 310, and thus includes multiple device identifiers (all protected) . However, the paging message can be addressed to the ambient IoT device 310 only (in which case it would include the corresponding device identifier only (also protected) ) or addressed to a group of ambient IoT devices (in which case it would include the corresponding group identifier only (also protected) ) .

[0046] In this step, the reader 320 protects the identifier (s) (device or group) included in the paging message. In particular, for each identifier to be included in the paging message, the reader 320 determines the corresponding random counter (e.g., from the memory) , combines (e.g., concatenates or appends) the two pieces of data (e.g., shown as “ID1||N1” ) , inputs the combined data to the hashing function, resulting in a hash (e.g., “HASH (ID1||N1) ” ) , and combines the hash with the random counter (e.g., concatenates or  appends, shown as “HASH (ID1||N1) ) ||N1” resulting in a protected identifier. The protected identifier is included in the paging message that is sent to the ambient IoT device 310. As explained above, the paging message can include multiple of such protected identifiers. If so, they can be included as a sequence in the paging message.

[0047] In optional steps of a random access procedure, the ambient IoT device 310 can send a Msg1 and a Msg2 to the reader 320. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 310 can send a Msg3 that also includes a protected identifier. Particularly, after receiving the paging message, the ambient IoT device 310 can determine whether this message is addressed to it by verifying the protected identifier. In particular, for each protected identifier included in the paging message, the ambient IoT device 310 determines the random counter included therein and not hashed (e.g., “N1” from “HASH (ID1||N1) ) ||N1” ) . Next, it uses this random counter as input along with its own pre-stored identifier (device or group) to a hashing function (e.g., the hashing function 132 of FIG. 1, applying the same algorithm as the hashing function 142) that outputs a hash of this identifier and the random counter. The hash is then compared to the hash from the protected identifier in the paging message (e.g., “HASH (ID1||N1) ) . ” If a match is found, the ambient IoT device 310 can determine that the protected identifier is verified and, thus, the paging message is addressed to it. Otherwise, it can process any other protected identifier including in the paging message until a match is found or all protected identifiers have been processed. If no match is found, the protected identifier is unverified, and the sequence diagram can end. Otherwise, the steps related to the random access procedure (including the sending of Msg 3 can be performed) .

[0048] Msg3 also includes a protected identifier. Here, the ambient IoT device 310 can generate a hash of the identifier (device or group) stored in its memory (shown as “HASH (ID1) ” ) . It may also be possible that this hash is pre-computed and stored in the memory to speed up the process. The hash is included in the Msg3 sent to the reader 320.

[0049] In a third step (shown with numeral “3” ) , the reader 320 can verify the protected identifier received in the Msg3. For instance, it can compute hashes of the identifiers stored in its memory (or these hashes can be pre-computed and pre-stored as described herein above) and can compare the received hash to these hashes to find a match. If a match is found, then the protected identifier is verified and the reader 320 can determine the  corresponding identifier (device or group from the mapping) and the sequence diagram can proceed. If no match is found, the protected identifier is unverified, and the sequence diagram can end. The verification can result in completing the random access procedure.

[0050] Next (shown with a numeral “4” ) , the reader 320 can send a downlink command to the ambient IoT device 310 for uplink data. In response (shown with a numeral “5”) , the ambient IoT device 310 can send an uplink message that includes the uplink data. Here, any or both of the downlink command and the uplink message can include an identifier (device or group) , and this identifier can be protected by using a hash, for example.

[0051] FIG. 4 illustrates another example of a sequence diagram for data protection of an ambient IoT device involving a hashing function, in accordance with various embodiments. The ambient IoT device 410 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device 410. In addition to the ambient IoT device 410, the sequence diagram involves a reader 420 (e.g., an example of the base station reader 220) , an AIoTF 430, a NEF 440, and an AF 450. The AIoTF 430 can be a function implemented in an operator network (e.g., the private network that includes the reader 420 and the ambient IoT device 410, such as by being implemented on the base station) . The NEF 440 and the AF 450 can be implemented in a core network (e.g., the core network 225) . Some of the steps of this sequence diagram are similar to those of FIG. 3. In the interest of brevity, the description of the similar steps from FIG. 3 is not repeated herein but equally applies to FIG. 4. Whereas in FIG. 3, a counter is randomly generated by the reader 320, here the ambient IoT device 410 generates such a counter.

[0052] In an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection, similar to the initial step of FIG. 3. Here, however, in sub-step “0d, ” the reader 320 need not compute and store random counters.

[0053] In a first step (labeled with numeral “1” ) , the reader 420 can send a paging message to one or more ambient IoT devices that the reader 420 is responsible for. This paging message can be in response to a service request of the core network. In FIG. 4, the paging message relates to multiple ambient IoT devices, including the ambient IoT device 410, and thus includes multiple device identifiers (all protected) . However, the paging message can be addressed to the ambient IoT device 410 only (in which case it would include the corresponding device identifier only (also protected) ) or addressed to a group of ambient  IoT devices (in which case it would include the corresponding group identifier only (also protected) ) .

[0054] In this step, the reader 420 protects the identifier (s) (device or group) included in the paging message. In particular, for each identifier to be included in the paging message, the reader 420 inputs the identifier to the hashing function, resulting in a hash (e.g., “HASH (ID1) ” ) . This hash can be a protected identifier. The protected identifier is included in the paging message that is sent to the ambient IoT device 410. As explained above, the paging message can include multiple of such protected identifiers. If so, they can be included as a sequence in the paging message.

[0055] In optional steps of a random access procedure, the ambient IoT device 410 can send a Msg1 and a Msg2 to the reader 420. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 410 can verify the protected identifier received in the paging message. This step can alternatively occur before the Msg1 and Msg2 stes. In an example, the ambient IoT device 410 computes (or has a pre-computed) a hash of its identifier stored in its memory and compares the hash to a protected identifier included in the paging message. If a match is found, this protected identifier is declared as verified. Otherwise, the ambient IoT device 410 similarly attempts to verify any other protected identifier included in the paging message until a match is found or until all protected identifier (s) is (are) processed and no match is found (in which case, the sequence diagram can end) . Assuming a match is found, the ambient IoT device 410 can generate a random counter (e.g., a random number, shown as “N1” ) , combine (e.g., concatenates or appends) this random counter with the identifier from its memory (shown as “ID1” ) , and input the combined data to the hashing function that outputs a hash (shown as “HASH (ID1||N1) ” ) . This hash is a protected identifier.

[0056] Next (shown as a third step with a numeral “3” ) , the ambient IoT device 410 can send a Msg3 that also includes the protected identifier along with the random number (e.g., a combination of the two show as “HASH (ID1||N1) ||N1” ) . This message corresponds to an identifier transmission.

[0057] In a fourth step (shown with a numeral “4” ) , the reader 420 verifies the protected identifier received in the Msg 3. Particularly, reader 420 determines the random counter included therein and not hashed (e.g., “N1” from “HASH (ID1||N1) ) ||N1” ) . Next, it uses this random counter as input, along with its own pre-stored identifier (device or group)  as input to a hashing function (e.g., the hashing function 142 of FIG. 1, applying the same algorithm as the hashing function 132) that outputs a hash of this identifier and the random counter. The hash is then compared to the hash from the protected identifier in the paging message (e.g., “HASH (ID1||N1) ) . ” If a match is found, the reader 420 can determine that the protected identifier is verified and, thus, the paging message is addressed to it. Otherwise, the protected identifier is unverified, and the sequence diagram can end.

[0058] Next (shown with a numeral “5” ) , the reader 420 can send a downlink command to the ambient IoT device 410 for uplink data. In response (shown with a numeral “6,” the ambient IoT device 410 can send an uplink message that includes the uplink data.

[0059] FIG. 5 illustrates yet an example of a sequence diagram for data protection of an ambient IoT device involving a hashing function, in accordance with various embodiments, in accordance with various embodiments. The ambient IoT device 510 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device 510. In addition to the ambient IoT device 510, the sequence diagram involves a reader 520 (e.g., an example of the base station reader 220) , an AIoTF 530, a NEF 540, and an AF 550. The AIoTF 530 can be a function implemented in an operator network (e.g., the private network that includes the reader 520 and the ambient IoT device 510, such as by being implemented on the base station) . The NEF 540 and the AF 550 can be implemented in a core network (e.g., the core network 225) . Some of the steps of this sequence diagram are similar to those of FIG. 3. In the interest of brevity, the description of the similar steps from FIG. 3 is not repeated herein but equally applies to FIG. 5. Whereas in FIGS. 3-4, a random counter is used, here a parameter is shared between the ambient IoT device 510 and the reader 520. This parameter can have a static value or a dynamic value that changes over time. In both cases, the data protection relies at least in part on the parameter to protect the identifier.

[0060] In an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection, similar to the initial step of FIG. 3. Here, however, in sub-step “0a, ” the ambient IoT device 510 is also configured with the shared parameter. For example, the ambient IoT device 510 stores logic defining the shared parameter and how its value can be updated over time. In one example, the shared parameter can include any or a combination of current date and / or out of band system index, although other parameters are possible. Further, in sub-step “0c, ” the AIoTF 530 configures  the reader 520 with the shared parameter of each ambient IoT device for which the reader 520 is responsible. For instance, the AIoTF 530 can send, to the reader 520, the definition, the value (s) , and / or the logic for controlling the shared parameter related to the ambient IoT device 510. In sub-step “0d, ” the reader 320 is not only configured with the identifiers (device or group) , but also with the shared parameters related to the ambient IoT devices. Each shared parameter is associated with an identifier (e.g., in a mapping that the reader 520) .

[0061] In a first step (labeled with numeral “1” ) , the reader 520 can send a paging message to one or more ambient IoT devices that the reader 520 is responsible for. This paging message can be in response to a service request of the core network. In FIG. 5, the paging message relates to multiple ambient IoT devices, including the ambient IoT device 510, and thus includes multiple device identifiers (all protected) . However, the paging message can be addressed to the ambient IoT device 510 only (in which case it would include the corresponding device identifier only (also protected) ) or addressed to a group of ambient IoT devices (in which case it would include the corresponding group identifier only (also protected) ) .

[0062] In this step, the reader 520 protects the identifier (s) (device or group) included in the paging message. In particular, for each identifier to be included in the paging message, the reader 520 determines the corresponding shared parameter (e.g., the value thereof) and inputs the identifier and this parameter (e.g., its value) to the hashing function, resulting in a hash (e.g., “HASH (ID1) ||Par_share” ) . This hash can be a protected identifier. The protected identifier is included in the paging message that is sent to the ambient IoT device 510. As explained above, the paging message can include multiple of such protected identifiers. If so, they can be included as a sequence in the paging message.

[0063] Next, the ambient IoT device 510 can verify the protected identifier received in the paging message. For example, it computes (or has a pre-computed) a hash of its identifier and the shared parameter (e.g., the value) and compares the hash to a protected identifier included in the paging message. If a match is found, this protected identifier is declared as verified. Otherwise, the ambient IoT device 510 similarly attempts to verify any other protected identifier included in the paging message until a match is found or until all protected identifier (s) is (are) processed and no match is found (in which case, the sequence diagram can end) .

[0064] Assuming a match is found, in optional steps of a random access procedure, the ambient IoT device 510 can send a Msg1 and a Msg2 to the reader 520. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 510 can generate and send a Msg3 to the reader 520. The Msg3 can correspond to a transmission of the identifier (device or group) stored in the ambient IoT device’s 510 memory. The identifier is protected, whereby the ambient IoT device 410 can input the identifier to the hashing function that outputs a hash (shown as “HASH (ID1) ” ) . This hash is a protected identifier.

[0065] In a third step (shown with numeral “3” ) , the reader 520 can verify the protected identifier received in the Msg3. For instance, it can compute hashes of the identifiers stored in its memory (or these hashes can be pre-computed and pre-stored as described herein above) and can compare the received hash to these hashes to find a match. If a match is found, then the protected identifier is verified and the reader 520 can determine the corresponding identifier (device or group from the mapping) and the sequence diagram can proceed. If no match is found, the protected identifier is unverified, and the sequence diagram can end. The verification can result in completing the random access procedure.

[0066] Next (shown with a numeral “4” ) , the reader 520 can send a downlink command to the ambient IoT device 510 for uplink data. In response (shown with a numeral “5” ) , the ambient IoT device 510 can send an uplink message that includes the uplink data.

[0067] Referring back to FIGS. 3-5, the above techniques can be thought of as implementing a lightweight solution with an encryption key. The lightweight solution involves using a dynamic temporary identifier, where the ambient IoT devices use different parameters to derive the corresponding temporary identifiers. In FIG. 3, the network sends the parameter (e.g., as a random value) to an ambient IoT device in a paging message when the device or group identifier is requested. In FIG. 4, an ambient IoT device sets the parameter (e.g., as a random value) and calculates and sends the temporary identifier along with the parameter. In FIG. 5, the parameter is pre-shared between the network and an ambient IoT device.

[0068] FIG. 6 illustrates an example of a sequence diagram for data protection of an ambient IoT device involving an encryption function, in accordance with various embodiments. The ambient IoT device 610 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device  610. In addition to the ambient IoT device 610, the sequence diagram involves a reader 620 (e.g., an example of the base station reader 220) , an AIoTF 630, a NEF 640, and an AF 650. The AIoTF 630 can be a function implemented in an operator network (e.g., the private network that includes the reader 620 and the ambient IoT device 610, such as by being implemented on the base station) . The NEF 640 and the AF 650 can be implemented in a core network (e.g., the core network 225) . Some of the steps of this sequence diagram are similar to those of FIG. 3. In the interest of brevity, the description of the similar steps from FIG. 3 is not repeated herein but equally applies to FIG. 6. Unlike FIGS. 3-5, an encryption key is used herein.

[0069] In an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection, similar to the initial step of FIG. 3. Here, however, in sub-step “0a, ” the ambient IoT device 610 is also configured with a key (e.g., a symmetric encryption key) . For example, the ambient IoT device 610 stores the key in its memory. In sub-step “0b, ” the AF 650 sends to the AIoTF 630, through the NEF 640, keys corresponding to different ambient IoT devices. Further, in sub-step “0c, ” the AIoTF 630 configures the reader 620 with the key of each ambient IoT device for which the reader 620 is responsible. For instance, the AIoTF 630 can send the relevant keys (e.g., symmetric keys) to the reader 620. Accordingly, in sub-step “0d, ” the reader 320 is not only configured with the identifiers (device or group) of the ambient devices it is responsible for, but also with the corresponding keys. Each key is associated with an identifier (e.g., stored in the reader’s 620 memory along with a mapping that associates each key with an identifier) .

[0070] In a first step (labeled with numeral “1” ) , the reader 620 can send a paging message to one or more ambient IoT devices that the reader 620 is responsible for. This paging message can be in response to a service request of the core network. In FIG. 6, the paging message relates to multiple ambient IoT devices, including the ambient IoT device 610, and thus includes multiple device identifiers (all protected) . However, the paging message can be addressed to the ambient IoT device 610 only (in which case it would include the corresponding device identifier only (also protected) ) or addressed to a group of ambient IoT devices (in which case it would include the corresponding group identifier only (also protected) ) .

[0071] In this step, the reader 620 protects the identifier (s) (device or group) included in the paging message. In particular, for each identifier to be included in the paging message,  the reader 620 determines the corresponding key (e.g., the value thereof) and inputs the identifier and this key to an encryption function (e.g., the encryption function 144 of FIG. 1) resulting in an encrypted identifier (e.g., “E_key1 (ID1) ” ) . This encrypted identifier can be a protected identifier. The protected identifier is included in the paging message that is sent to the ambient IoT device 610. As explained above, the paging message can include multiple of such protected identifiers. If so, they can be included as a sequence in the paging message.

[0072] Next, the ambient IoT device 610 can verify the protected identifier received in the paging message. For example, the ambient IoT device 610 inputs the protected identifier into an encryption function (e.g., the encryption function 134 of FIG. 1) that attempts to decrypt the protected identifier by using the key stored in the ambient IoT device’s 610 memory. If successful, the protected identifier is verified. Otherwise, the ambient IoT device 610 similarly attempts to verify any other protected identifier included in the paging message until a match is found or until all protected identifier (s) is (are) processed and no protected identifier is successfully decrypted (in which case, the sequence diagram can end) . In another example, the ambient IoT device 610 can encrypt, using the key in its memory, the identifier stored in its memory resulting in an encrypted identifier. This encrypted identifier can be compared to the protected identifier (s) included in the paging message to determine a match. If a match is found the matched protected identifier is declared verified. Otherwise, no protected identifier is verified.

[0073] Assuming a verification occurs, in optional steps of a random access procedure, the ambient IoT device 610 can send a Msg1 and a Msg2 to the reader 620. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 610 can generate and send a Msg3 to the reader 620. The Msg3 can correspond to a transmission of the identifier (device or group) stored in the ambient IoT device’s 610 memory. The identifier is protected, whereby the ambient IoT device 410 can input the identifier to the hashing function that outputs a hash (shown as “HASH (ID1) ” ) . This hash is a protected identifier.

[0074] In a third step (shown with numeral “3” ) , the reader 620 can verify the protected identifier received in the Msg3. For instance, it can compute hashes of the identifiers stored in its memory (or these hashes can be pre-computed and pre-stored as described herein above) and can compare the received hash to these hashes to find a match. If a match is found, then the protected identifier is verified and the reader 620 can determine the  corresponding identifier (device or group from the mapping) and the sequence diagram can proceed. If no match is found, the protected identifier is unverified, and the sequence diagram can end. The verification can result in completing the random access procedure.

[0075] Next (shown with a numeral “4” ) , the reader 620 can send a downlink command to the ambient IoT device 610 for uplink data. In response (shown with a numeral “5” ) , the ambient IoT device 610 can send an uplink message that includes the uplink data.

[0076] In a variation to the second step, rather than protecting the identifier with a hash, the identifier can be encrypted. For example, the ambient IoT device 610 inputs the identifier stored in its memory to the encryption function that uses the key stored in the memory to encrypt the identifier, resulting in an encrypted identifier. A clear portion (e.g., an unencrypted portion) of the identifier (e.g., the three least significant bits) is also combined with (e.g., concatenated with or appended to) the encrypted identifier resulting in the protected identifier that is sent in the Msg 3. In the third step, the reader 620 can determine the clear portion from the Msg3 and use it as an index to look up the corresponding identifier stored in the reader’s 620 memory. Here, the reader 620 can decrypt the encrypted identifier form the Msg3 and compare the result with the looked up identifier. Alternatively, the reader 620 can encrypt the looked up identifier using the corresponding key and compare the encryption result with the encrypted identifier included in the Msg3.

[0077] FIG. 7 illustrates another example of a sequence diagram for data protection of an ambient IoT device involving an encryption function, in accordance with various embodiments. The ambient IoT device 710 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device 710. In addition to the ambient IoT device 710, the sequence diagram involves a reader 720 (e.g., an example of the base station reader 220) , an AIoTF 730, a NEF 740, and an AF 750. The AIoTF 730 can be a function implemented in an operator network (e.g., the private network that includes the reader 720 and the ambient IoT device 710, such as by being implemented on the base station) . The NEF 740 and the AF 750 can be implemented in a core network (e.g., the core network 225) . Some of the steps of this sequence diagram are similar to those of FIG. 3. In the interest of brevity, the description of the similar steps from FIG. 3 is not repeated herein but equally applies to FIG. 7. Whereas in FIG. 6, only the identifier is encrypted, here an entire message can be encrypted.

[0078] In an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection, similar to the initial step of FIG. 6. In a first step (labeled with numeral “1” ) , the reader 720 can send a paging message to one or more ambient IoT devices that the reader 720 is responsible for, similar to the first step of FIG. 6. Next, the ambient IoT device 710 can verify the protected identifier received in the paging message similar to the verification of FIG. 6.

[0079] Assuming a verification occurs, in optional steps of a random access procedure, the ambient IoT device 710 can send a Msg1 and a Msg2 to the reader 720. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 710 can generate and send a Msg3 to the reader 720. The Msg3 can correspond to a transmission of the identifier (device or group) stored in the ambient IoT device’s 710 memory. Here, the ambient IoT device 720 can encrypt the entire message by using the key stored in its memory, resulting in an encrypted message (e.g., E_key (Device ID transmission: (ID1) ) ) . The ambient IoT device 710 can also determine a clear portion (e.g., an unencrypted portion) of the identifier (e.g., the three least significant bits) . This clear portion can be sent along with the Msg3 (or as an additional field in the Msg3, where this field is not encrypted) .

[0080] In a third step of the sequence diagram (shown with number “3” ) , the reader 720 can verify the encrypted identifier. For example, the reader 720 can determine the clear portion and use it as an index to look up the corresponding identifier stored in the reader’s 720 memory. The reader 720 can decrypt the encrypted identifier form the Msg3 and compare the result with the looked up identifier. Alternatively, the reader 720 can encrypt the looked up identifier using the corresponding key and compare the encryption result with the encrypted identifier included in the Msg3.

[0081] Next (shown with a numeral “4” ) , the reader 720 can send a downlink command to the ambient IoT device 710 for uplink data. In response (shown with a numeral “5” ) , the ambient IoT device 710 can send an uplink message that includes the uplink data.

[0082] Referring back to FIGS. 6-7, the above techniques can be thought of as implementing a key-based solution. The relevant key is provisioned into an ambient IoT device in manufacturing time. The key also is configured into a reader along with the relevant identifier. In FIG. 6, when the identifier can be encrypted. In FIG. 7, a message that includes the key can be encrypted.

[0083] FIG. 8 illustrates an example of a sequence diagram for data protection of an ambient IoT device involving a one-time identifier, in accordance with various embodiments. The ambient IoT device 810 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device 810. In addition to the ambient IoT device 810, the sequence diagram involves a reader 820 (e.g., an example of the base station reader 220) , an AIoTF 830, a NEF 840, and an AF 850. The AIoTF 830 can be a function implemented in an operator network (e.g., the private network that includes the reader 820 and the ambient IoT device 810, such as by being implemented on the base station) . The NEF 840 and the AF 850 can be implemented in a core network (e.g., the core network 225) . Some of the steps of this sequence diagram are similar to those of FIG. 3. In the interest of brevity, the description of the similar steps from FIG. 3 is not repeated herein but equally applies to FIG. 8. Unlike FIGS. 3-7, a one-time identifier is used herein.

[0084] In an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection, similar to the initial step of FIG. 3. Here, however, in sub-step “0a, ” the ambient IoT device 810 is configured with multiple device identifiers (e.g., “N” IDs) and indexes, each of which corresponds to one of the identifiers (e.g., “N1” corresponding to “ID1, ” “N2” corresponding to “ID2, ” etc. ) . The ambient IoT device 810 stores the identifiers and corresponding indexes in its memory, along with a mapping that associates each index with an identifier. Each identifier can be a device identifier or a group identifier. Each identifier (or, equivalently, index) can be a limited number of use identifier (e.g., a one-time use identifier, where it can be used only once to identify the ambient IoT device 810 to the reader 820) and / or a limited duration identifier (e.g., an identifier with an expiration date or a valid time frame after which the identifier is no longer usable to identify the ambient IoT device 810 to the reader 820) .

[0085] In sub-step “0b, ” the AF 850 sends to the AIoTF 830, through the NEF 840, identifiers corresponding to different ambient IoT devices (e.g., “N” IDs per device, where the total number of identifiers per device can vary) and the corresponding indexes. Further, in sub-step “0c, ” the AIoTF 830 configures the reader 820 with the device identifiers and corresponding indexes of each ambient IoT device for which the reader 820 is responsible. For instance, the AIoTF 830 can send the relevant identifiers and indexes to the reader 820. Accordingly, in sub-step “0d, ” the reader 320 is not only configured with the identifiers (device or group) of the ambient devices it is responsible for, but also with the corresponding indexes. Each index is associated with an identifier (e.g., stored in the reader’s 820 memory  along with a mapping that associates each identifier with an identifier) . Although an index is described as being a piece of data separate from a corresponding identifier (e.g, “N1” corresponding to “ID1” ) , the index can be part of identifier (e.g., “ID1-1” ) .

[0086] In a first step (labeled with numeral “1” ) , the reader 820 can send a paging message to one or more ambient IoT devices that the reader 820 is responsible for. This paging message can be in response to a service request of the core network. In FIG. 8, the paging message relates to multiple ambient IoT devices, including the ambient IoT device 810, and thus includes multiple device identifiers (all protected) . However, the paging message can be addressed to the ambient IoT device 810 only (in which case it would include the corresponding device identifier only (also protected) ) or addressed to a group of ambient IoT devices (in which case it would include the corresponding group identifier only (also protected) ) . In this step, the reader 820 includes the identifier (s) (device or group) in the paging message. No hashing or encryption may be applied.

[0087] Next, the ambient IoT device 810 can verify the identifier received in the paging message. For example, the ambient IoT device 810 compares the received identifier with the identifiers stored in its memory. If am match is found, the identifier is verified. Additionally, here, the validation can involve the ambient IoT device 810 determining whether the matched identifier is valid. For instance, if this identifier has not expired yet or its previous number of uses has not exceeded the limited number of uses, then it is still valid. Different techniques are possible for this determination. In one technique, the ambient IoT device 810 can maintain a validity status (e.g., a flag or bit) in its memory for each stored index indicating whether it is still valid or not. Alternatively, the ambient IoT device 810 can store a count of the previous number of uses and / or a remainder of the validity period. As long as the current count or time has not exceeded the limited number of uses or validity time period, then the matched identifier is verified.

[0088] Assuming a verification occurs, in optional steps of a random access procedure, the ambient IoT device 810 can send a Msg1 and a Msg2 to the reader 820. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 810 can generate and send a Msg3 to the reader 820. The Msg3 can correspond to a transmission of the identifier (device or group) stored in the ambient IoT device’s 810 memory. Here, the ambient device can include, in the Msg3, the identifier and the corresponding index stored in its memory. In one example, the  identifier included in the Msg3 can correspond to the identifier received in the paging message (which the ambient IoT device 810 has determined to be still valid) . In this example, the ambient IoT device 810 determines the index associated with the identifier received in the paging message and includes the index in the Msg3. In another example, the ambient IoT device 810 can select any of the identifiers that are stored in its memory and that are still valid (e.g., the next available valid identifier) , determine the corresponding index, and include both in the Msg 3.

[0089] In a third step (shown with numeral “3” ) , the reader 820 can verify the identifier received in the Msg3. For instance, it can compare the received identifier with identifiers stored in its memory. If a match is found, the received identifier is declared as being verified. In a further example, the received index can be used in the verification as well. For example, the index of the matched identifier is looked up and is matched with the received index. Additionally, the reader 820 can maintain the indexes stored in its memory. For instance, any time an identifier is used (e.g., included in a Msg3) , the corresponding index is determined and updated. The update can include changing the value of the index (e.g., incrementing it) or its status (e.g., to invalid depending on a comparison of the index’s current value to a maximum number of uses, or based on the current time and the index’s validity period) . In such cases, the received index can be matched with an updated, valid index.

[0090] Next (shown with a numeral “4” ) , the reader 820 can send a downlink command to the ambient IoT device 810 for uplink data. Here, the identifier and the corresponding can be included in the Msg4 (which allows the ambient IoT device 810 to use the index for the verification of the identifier) . In a next step (shown with numeral “5” ) , the ambient IoT device 810 can verify the received identifier (similar to the verification related to the paging message or the verification that the reader 820 implement) . Further, the ambient IoT device 810 can update the status or the counter of the identifier such that it becomes invalid the next time an identifier needs to be used. From that point, another identifier can be used.

[0091] FIG. 9 illustrates another example of a sequence diagram for data protection of an ambient IoT device involving a one-time identifier, in accordance with various embodiments. The ambient IoT device 910 is an example of the ambient IoT device 210 of FIG. 2. The data protection is applied to an identifier associated with the ambient IoT device  910. In addition to the ambient IoT device 910, the sequence diagram involves a reader 920 (e.g., an example of the base station reader 220) , an AIoTF 930, a NEF 940, and an AF 950. The AIoTF 930 can be a function implemented in an operator network (e.g., the private network that includes the reader 920 and the ambient IoT device 910, such as by being implemented on the base station) . The NEF 940 and the AF 950 can be implemented in a core network (e.g., the core network 225) . Some of the steps of this sequence diagram are similar to those of FIG. 8. In the interest of brevity, the description of the similar steps from FIG. 8 is not repeated herein but equally applies to FIG. 9. In comparison to FIG. 8, an ambient IoT device is configured with a smaller number of identifiers (e.g., one device identifier) , and each identifier is associated with an index.

[0092] In an initial step (shown with numerals “0a, ” “0b, ” “0c” , and “0d” ) , configuration information is distributed to enable the protection, similar to the initial step of FIG. 8. Here, however, in sub-step “0a, ” the ambient IoT device 910 is configured with a device identifier (e.g., “ID1-1” ) and an index corresponding to this identifier. The ambient IoT device 910 stores the identifier and the index in its memory, along with a mapping that associates the index with the identifier. The identifier can be a limited number of use identifier and / or a limited duration identifier. The index itself need not be a limited use index (e.g., whereas the identifier may be used one, the index may be used multiple times) . Similarly, if the ambient IoT device 910 is part of a group, it is configured with a group identifier and a corresponding index.

[0093] In sub-step “0b, ” the AF 950 sends to the AIoTF 930, through the NEF 940, identifiers corresponding to different ambient IoT devices (e.g., “N” IDs per device, where the total number of identifiers per device can vary) and the corresponding indexes. Further, in sub-step “0c, ” the AIoTF 930 configures the reader 920 with the device identifiers and corresponding indexes of each ambient IoT device for which the reader 920 is responsible. For instance, the AIoTF 930 can send the relevant identifiers and indexes to the reader 920. Accordingly, in sub-step “0d, ” the reader 320 is not only configured with the identifiers (device or group) of the ambient devices it is responsible for, but also with the corresponding indexes. Each index is associated with an identifier (e.g., stored in the reader’s 920 memory along with a mapping that associates each identifier with an identifier) .

[0094] In a first step (labeled with numeral “1” ) , the reader 920 can send a paging message to one or more ambient IoT devices that the reader 920 is responsible for. This  paging message can be in response to a service request of the core network. In FIG. 9, the paging message relates to multiple ambient IoT devices, including the ambient IoT device 910, and thus includes multiple device identifiers (all protected) . However, the paging message can be addressed to the ambient IoT device 910 only (in which case it would include the corresponding device identifier only (also protected) ) or addressed to a group of ambient IoT devices (in which case it would include the corresponding group identifier only (also protected) ) . In this step, the reader 920 includes the identifier (s) (device or group) in the paging message. No hashing or encryption may be applied. In an example, an identifier included in the padding message takes the form of “IDm-n” indicating the “n-th” identifier for the ambient IoT device “m. ”

[0095] Next, the ambient IoT device 910 can verify the identifier received in the paging message. For example, the ambient IoT device 910 compares the received identifier with the identifier (s) stored in its memory. If a match is found, the identifier is verified. Additionally, here, the validation can involve the ambient IoT device 910 determining whether the matched identifier is valid. For instance, if this identifier has not expired yet or its previous number of uses has not exceeded the limited number of uses, then it is still valid. Different techniques are possible for this determination.

[0096] Assuming a verification occurs, in optional steps of a random access procedure, the ambient IoT device 910 can send a Msg1 and a Msg2 to the reader 920. In a second step of the sequence diagram (shown with numeral “2” and corresponding to a step of the random access procedure) , the ambient IoT device 910 can generate and send a Msg3 to the reader 920. The Msg3 can correspond to a transmission of the identifier (device or group) stored in the ambient IoT device’s 910 memory. Here, the ambient device can include, in the Msg3, the identifier and the corresponding index stored in its memory. In one example, the identifier included in the Msg3 can correspond to the identifier received in the paging message (which the ambient IoT device 910 has determined to be still valid) . In this example, the ambient IoT device 910 determines the index associated with the identifier received in the paging message and includes the index in the Msg3.

[0097] In a third step (shown with numeral “3” ) , the reader 920 can verify the identifier received in the Msg3. For instance, it can compare the received identifier with identifiers stored in its memory. If a match is found, the received identifier is declared as being verified. In a further example, the received index can be used in the verification as  well. For example, the index of the matched identifier is looked up and is matched with the received index.

[0098] Next (shown with a numeral “4” ) , the reader 920 can send a downlink command to the ambient IoT device 910 for uplink data. Here, the identifier and the corresponding can be included in the Msg4 (which allows the ambient IoT device 910 to use the index for the verification of the identifier) . In a next step (shown with numeral “5” ) , the ambient IoT device 910 can verify the received identifier (similar to the verification related to the paging message or the verification that the reader 920 implement) . Further, the ambient IoT device 910 can update the status or the counter of the identifier such that it becomes invalid the next time an identifier needs to be used. From that point, another identifier can be used. In particular, the next identifier can be a hash of the previous identifier (e.g., “ID1-2=HASH (ID1-1) , or more generally “IDm-n+1=HASH (IDm-n) ” ) . The index need not be updated and can be associated with the next identifier when this next identifier is generated. The reader 820 can implement (e.g., at the third step) a similar update to the identifier and can associate the updated identifier with the same index. In this way, both the reader 820 and the ambient IoT device 810 can continue verifying their exchanged identifiers.

[0099] Referring back to FIGS. 8-9, the above techniques can be thought of as implementing a one-time device ID, considering that an AIoT device may only have limited capability and storage with a short lifetime and limited times to send a device ID uplink. In this case, a cryptographic-based solution may be less advantageous. Instead, a few device IDs can be assigned for each ambient IoT device, every time when an ambient IoT device needs to send IDs uplink, it can use one Device ID together with a counter. In FIG. 8, an ambient IoT device stores multiple device IDs together with indexes. In FIG. 9, an ambient IoT device uses a hash chain to generate one-time device IDs on-demand. The new one-time device ID is derived from the latest device ID sent uplink. To avoid un-synchronization, an index can be used to identify the device ID.

[0100] FIG. 10 illustrates an example of an operational flow / algorithmic structure 1000 implemented by an ambient IoT device in support of data protection, in accordance with various embodiments. The ambient IoT device can be any of the ambient IoT devices described herein. The operational flow / algorithmic structure 1000 can be implemented by an apparatus of the ambient IoT device (e.g., the apparatus includes processing circuitry) . In some embodiments, the operational flow / algorithmic structure 1000 may be implemented by  executing instructions stored in a tangible, non-transitory, computer-readable storage medium, such as a memory of the ambient IoT device. While the operational flow / algorithmic structure 1000 is described using steps in a specific sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in different sequences than the sequence illustrated, and certain described steps may be omitted or not performed altogether.

[0101] In an example, the operational flow / algorithmic structure 1000 includes, at 1002, receiving, from a network node, a first message indicating an identifier of an ambient Internet of Things (IoT) device. For instance, the identifier can be a device identifier or a group identifier. The first message can be a paging message. The identifier may be protected by being hashed, being encrypted, or being a limited number of use identifier or a limited time duration identifier as described in FIGS. 3-9.

[0102] In an example, the operational flow / algorithmic structure 1000 includes, at 1004, verifying the identifier based on a first identifier protection procedure. The verification can depend on the type of protection and can be performed according to any of the applicable sequence diagrams of FIGS. 3-9. Prior to operation 1002, the identifier may have been protected by the network node according to the first identifier protection procedure (e.g., the identifier protection procedure 142 of FIG. 1) . Depending on this procedure, the ambient IoT device can apply a verification technique (e.g., when the identifier is protected with a hash, the ambient IoT device can apply a hashing function as part of the verification) .

[0103] In an example, the operational flow / algorithmic structure 1000 includes, at 1006, generating a second message based on the identifier being verified, wherein the identifier is protected in the second message based on a second identifier protection procedure. For instance, the message is a random access message, such as a Msg3. The second identifier protection procedure can, but need not, be different from the first identifier procedure. In particular, the protection here can involve a hashing function, an encryption function, or the use of an index associated with a limited number of use identifier or a limited time duration identifier and can correspond to the protection described in the applicable sequence diagram of FIGS. 3-9.

[0104] In an example, the operational flow / algorithmic structure 1000 includes, at 1008, sending, to the network node in support of a subsequent data exchange between the network node and the ambient IoT device, the second message that indicates the identifier.  For instance, the second message is sent to access the network such that uplink data can be subsequently sent.

[0105] FIG. 11 illustrates an example of an operational flow / algorithmic structure 1100 implemented by a reader in support of data protection, in accordance with various embodiments. The reader is an example of a network node. The operational flow / algorithmic structure 1100 can also be implemented by different types of network nodes (e.g., and / or an apparatus of the network node, where the apparatus includes processing circuitry) that may be communicatively coupled over an air interface with an ambient IoT device. The network node can be any of the network nodes described herein. In some embodiments, the operational flow / algorithmic structure 1100 may be implemented by executing instructions stored in a tangible, non-transitory, computer-readable storage medium, such as a memory of the network node. While the operational flow / algorithmic structure 1100 is described using steps in a specific sequence, it should be understood that the present disclosure contemplates that the described steps may be performed in different sequences than the sequence illustrated, and certain described steps may be omitted or not performed altogether.

[0106] In an example, the operational flow / algorithmic structure 1100 includes, at 1102, sending, an ambient Internet of Things (IoT) device, a paging message indicating an identifier of the ambient IoT device, the identifier protected in the paging message based on a first identifier protection procedure. For instance, the identifier can be a device identifier or a group identifier. The identifier may be protected by being hashed, being encrypted, or being a limited number of use identifier or a limited time duration identifier as described in FIGS. 3-9.

[0107] In an example, the operational flow / algorithmic structure 1100 includes, at 1104, receiving, from the ambient IoT device, a random access message indicating the identifier, the identifier protected in the random access message based on a second identifier protection procedure. For instance, this message is a Msg3. The second identifier protection procedure can, but need not, be different from the first identifier procedure. In particular, the protection can involve a hashing function, an encryption function, or the use of an index associated with a limited number of use identifier or a limited time duration identifier and can correspond to the protection described in the applicable sequence diagram of FIGS. 3-9.

[0108] In an example, the operational flow / algorithmic structure 1100 includes, at 1106, verifying , the identifier indicated in the random access message. The verification can  depend on the type of protection and can be performed according to any of the applicable sequence diagrams of FIGS. 3-9. For instance, depending on the second identifier protection procedure, the reader can apply a verification technique (e.g., when the identifier is protected with a hash, the reader can apply a hashing function as part of the verification) .

[0109] In an example, the operational flow / algorithmic structure 1100 includes, at 1108, exchanging data with the ambient IoT device based on the verifying. Upon the identifier being verified, a command can be sent to the ambient IoT device to send uplink data.

[0110] FIG. 12 illustrates an ambient IoT device 1200, in accordance with some embodiments. The ambient IoT device 1200 is an example of the ambient IoT devices described herein above. For example, the ambient IoT device 1200 can have an energy harvesting source and limited processing capabilities. The ambient IoT device 1200 an implement any of the identifier protection procedures described in FIGS. 3-9 to protect and / or verify an identifier exchanged with a network and.

[0111] In an example, the ambient IoT device 1200 includes a power source 1212 that can supply power to other components of the ambient IoT device 1200. The power source 1212 can include a power storage component (e.g., a set of capacitors, a rechargeable battery cell, etc. ) and an energy harvesting component (e.g., a solar panel) . The other components can include at least a processor 1202, a memory 1204, input / output peripherals (I / O) 1208, communication peripherals 1210, and sensors 1214. An interface bus can be configured to communicate, transmit, and transfer data, controls, and commands among the various components of the ambient IoT device 1200. The memory 1204 can include computer-readable storage media, such as RAM; ROM; electrically erasable programmable read-only memory (EEPROM) ; hard drives; CD-ROMs; optical storage devices; magnetic storage devices; electronic non-volatile computer storage, for example,  memory; and other tangible storage media. Any of such computer readable storage media can be configured to store instructions or program codes embodying aspects of the disclosure. The memory 1204 can also include computer readable signal media. A computer readable signal medium includes a propagated data signal with computer readable program code embodied therein. Such a propagated signal takes any of a variety of forms including, but not limited to, electromagnetic, optical, or any combination thereof. A computer readable signal medium includes any computer readable medium that is not a computer readable storage medium and  that can communicate, propagate, or transport a program for use in connection with the ambient IoT device 1200.

[0112] Further, the memory 1204 includes an operating system, programs, and applications. The processor 1202 is configured to execute the stored instructions and includes, for example, a logical processing unit, a microprocessor, a digital signal processor, and other processors. The I / O peripherals 1208 can include user interfaces, such as a light source; an alarm device; a keyboard; screen (e.g., a touch screen) ; microphone; speaker; other input / output devices; and computing components, such as graphical processing units; serial ports; parallel ports; universal serial buses; and other input / output peripherals. The sensors 1214 can be configured to detect events or changes in their environment and send the information (sensor data) about the detected events to some other device, module, or system. Examples of such sensors 1214 include inertia measurement units comprising accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems comprising 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; flow sensors; temperature sensors (for example, thermistors) ; pressure sensors; barometric pressure sensors; gravimeters; altimeters; image capture devices (for example, cameras or lens-less apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; and microphones or other like audio capture devices. The communication peripherals 1210 are configured to facilitate communication between the ambient IoT device 1200 and other systems over a communications network and include, for example, a network interface controller, modem, wireless and wired interface cards, antenna, and other communication peripherals.

[0113] FIG. 13 illustrates a reader 100, in accordance with some embodiments. The reader 1300 may be similar to and substantially interchangeable with the base station reader 120 of FIG. 1. Particularly, the reader 1300 can be a network node of a network and can provide an ambient IoT device with access to the network. The access can rely on an exchange of an identifier associated with he IoT device. The reader 1300 can protect and / or verify the identifier by using an identifier protection technique such as any of the techniques described in FIGS. 3-9.

[0114] The reader 1300 may include processors 1304, RAN interface circuitry 1308, core network (CN) interface circuitry 1312, and memory / storage circuitry 1316. The  components of the reader 1300 may be coupled with various other components over one or more interconnects 1328.

[0115] The CN interface circuitry 1312 may provide connectivity to a core network, for example, a Fifth Generation Core network (5GC) using a 5GC-compatible network interface protocol, such as carrier Ethernet protocols, or some other suitable protocol. Network connectivity may be provided to / from the reader 1300 via a fiber optic or wireless backhaul. The CN interface circuitry 1312 may include one or more dedicated processors or FPGAs to communicate using one or more of the aforementioned protocols. In some implementations, the CN interface circuitry 1312 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0116] Examples

[0117] In the following sections, further exemplary embodiments are provided.

[0118] Example 1 includes a method comprising: receiving, from a network node, a first message indicating an identifier of an ambient Internet of Things (IoT) device; verifying the identifier based on a first identifier protection procedure; generating a second message based on the identifier being verified, wherein the identifier is protected in the second message based on a second identifier protection procedure; and sending, to the network node in support of a subsequent data exchange between the network node and the ambient IoT device, the second message that indicates the identifier.

[0119] Example 2 includes a method comprising: sending, to an ambient Internet of Things (IoT) device, a paging message indicating an identifier of the ambient IoT device, the identifier protected in the paging message based on a first identifier protection procedure; receiving, from the ambient IoT device, a random access message indicating the identifier, the identifier protected in the random access message based on a second identifier protection procedure; verifying the identifier indicated in the random access message; and exchanging data with the ambient IoT device based on the verifying.

[0120] Example 3 includes the method of example 1, wherein the first message is a paging message, and wherein the second message is a random access procedure message.

[0121] Example 4 includes the method of any example 1-3, wherein the first identifier protection procedure or the second identifier protection procedure includes at least one of: hashing the identifier and a parameter that is randomly generated by the network node or the  ambient IoT device or that is shared between the network node and the ambient IoT device, encrypting of at least the identifier, or using a one-time device identifier.

[0122] Example 5 includes the method of any example 1-4, wherein the first message or the paging message includes a random number and a first hash of the identifier and of the random number, and wherein the second message or the random access message includes a second hash of the identifier.

[0123] Example 6 includes the method of example 5, wherein the identifier is verified by at least: determining the random number from the first message; generating, from a pre-stored identifier of the ambient IoT device, a third hash of the pre-stored identifier and the random number; and determining a match between the first hash and the third hash.

[0124] Example 7 includes the method of any example 1-6, wherein the first message or the paging message includes a first hash of the identifier, and wherein the second message or the random access message includes a random number and a second hash of the identifier and of the random number.

[0125] Example 8 includes the method of example 7, further comprising: generating, from a pre-stored identifier of the ambient IoT device, a third hash of the pre-stored identifier; determining a match between the first hash and the third hash; generating, based on the match, the random number; and including, in the second message, the random number and the second hash.

[0126] Example 9 includes the method of any example 1-8, wherein the first message or the paging message includes a first hash of the identifier and of a value of a parameter, wherein the parameter is shared between the network node and the ambient IoT device, and wherein the second message or the random access message includes a second hash of the identifier.

[0127] Example 10 includes the method of example 9, wherein the identifier is verified by at least: determining a pre-stored identifier of the ambient IoT device and a pre-stored value of the parameter; generating a third hash of the pre-stored identifier and the pre-stored value; and determining a match between the first hash and the third hash.

[0128] Example 11 includes the method of any example 1-10, wherein the first message or the paging message includes an encryption of the identifier, and wherein the second message or the random access message includes a hash of the identifier.

[0129] Example 12 includes the method of example 11, wherein the identifier is verified by at least: determining the identifier from the paging message based on a pre-stored decryption key.

[0130] Example 13 includes the method of any example 1-12, wherein the first message or the paging message includes a first encryption of the identifier, and wherein the second message or the random access message includes a second encryption of the identifier and an unencrypted portion of the identifier.

[0131] Example 14 includes the method of any example 1-13, wherein the first message or the paging message includes an encryption of the identifier, and wherein the second message or the random access message is encrypted and is sent along with an unencrypted portion of the identifier.

[0132] Example 15 includes the method any example 1-14, wherein the identifier is associated with at least one of: a limited number of usage or a limited time duration for the usage, wherein the paging message includes the identifier.

[0133] Example 16 includes the method of example any example 1-15, wherein the second message or the random access message includes the identifier and an index associated with the identifier.

[0134] Example 17 includes the method of example 16, wherein the identifier is verified by at least determining a match between the index and a pre-stored index associated with the usage of the identifier, and wherein the method further comprises: sending, to the ambient IoT device and subsequent to the random access message, an additional message that includes the index and the identifier.

[0135] Example 18 includes the method of example 16, wherein the identifier, the index, and the random access message are a first identifier, a first index, and a first random access message, respectively, and wherein the method further comprises: storing a first association between the first identifier and the first index and a second association between a second identifier of the ambient IoT device and a second index, wherein the first index is verified based on the first association; receiving, from the ambient IoT device, a second random access message that includes the second identifier and the second index; and verifying the second identifier based on the second association.

[0136] Example 19 includes the method of example 16, wherein the identifier, the index, and the random access message are a first identifier, a first index, and a first random access message, respectively, and wherein the method further comprises: receiving, from the ambient IoT device, a second random access message that includes a second identifier that is a hash of the first identifier and the second index; and verifying the second identifier based on the hash value and the index.

[0137] Example 20 includes a user equipment (UE) or an apparatus comprising: one or more processors; and one or more memory storing instructions that, upon execution by the one or more processors, configure the UE or the apparatus to perform a method described in or related to any of the preceding examples.

[0138] Example 21 includes one or more computer-readable media storing instructions that, when executed on a user equipment (UE) or an apparatus, cause the UE or the apparatus to perform operations comprising those of a method described in or related to any of the preceding examples.

[0139] Example 22 includes an apparatus comprising means to perform one or more elements of a method described in or related to any of the preceding examples.

[0140] Example 23 includes one or more non-transitory computer-readable media comprising instructions to cause an apparatus, upon execution of the instructions by one or more processors of the apparatus, to perform one or more elements of a method described in or related to any of the preceding examples.

[0141] Example 24 includes an apparatus comprising logic, modules, or processing circuitry configured to perform one or more elements of a method described in or related to any of the preceding examples.

[0142] Example 25 includes an apparatus, a reader, a network node, a base station, or a system comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform one or more elements of a method described in or related to any of the preceding examples.

[0143] It is well understood that the use of personally identifiable information should follow privacy policies and practices that are generally recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy of users. In particular,  personally identifiable information data should be managed and handled so as to minimize risks of unintentional or unauthorized access or use, and the nature of authorized use should be clearly indicated to users.

[0144] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, or methods as set forth in the example section below. For example, the baseband circuitry as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth below in the example section.

[0145] Any of the above-described examples may be combined with any other example (or combination of examples) , unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0146] Although the embodiments above have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.

Claims

1.A method comprising:receiving, from a network node, a first message indicating an identifier of an ambient Internet of Things (IoT) device;verifying the identifier based on a first identifier protection procedure;generating a second message based on the identifier being verified, wherein the identifier is protected in the second message based on a second identifier protection procedure; andsending, to the network node in support of a subsequent data exchange between the network node and the ambient IoT device, the second message that indicates the identifier.2.The method of claim 1, wherein the first message is a paging message, and wherein the second message is a random access procedure message.3.The method of claim 1, wherein the second identifier protection procedure includes at least one of: hashing the identifier and a parameter that is randomly generated by the network node or the ambient IoT device or that is shared between the network node and the ambient IoT device, encrypting of at least the identifier, or using a one-time device identifier.4.The method of claim 1, wherein the first message includes a random number and a first hash of the identifier and of the random number, and wherein the second message includes a second hash of the identifier.5.The method of claim 4, wherein the identifier is verified by at least:determining the random number from the first message;generating, from a pre-stored identifier of the ambient IoT device, a third hash of the pre-stored identifier and the random number; anddetermining a match between the first hash and the third hash.6.The method of claim 1, wherein the first message includes a first hash of the identifier, and wherein the second message includes a random number and a second hash of the identifier and of the random number.7.The method of claim 6, further comprising:generating, from a pre-stored identifier of the ambient IoT device, a third hash of the pre-stored identifier;determining a match between the first hash and the third hash;generating, based on the match, the random number; andincluding, in the second message, the random number and the second hash.8.The method of claim 1, wherein the first message includes a first hash of the identifier and of a value of a parameter, wherein the parameter is shared between the network node and the ambient IoT device, and wherein the second message includes a second hash of the identifier.9.The method of claim 8, wherein the identifier is verified by at least:determining a pre-stored identifier of the ambient IoT device and a pre-stored value of the parameter;generating a third hash of the pre-stored identifier and the pre-stored value; anddetermining a match between the first hash and the third hash.10.An apparatus comprising:processing circuitry configured to be powered by an energy source of an ambient Internet of Things (IoT) device and further configured to:process a paging message indicating an identifier of the ambient IoT device;verify the identifier based on a first identifier protection procedure;generating, based on the identifier being verified, a random access message, the identifier being protected in the random access message based on a second identifier protection procedure; andcause transmission of the random access message, the random access message indicating the identifier.11.The apparatus of claim 10, wherein the paging message includes an encryption of the identifier, and wherein the random access message includes a hash of the identifier.12.The apparatus of claim 11, wherein the identifier is verified by at least:determining the identifier from the paging message based on a pre-stored decryption key.13.The apparatus of claim 10, wherein the paging message includes a first encryption of the identifier, and wherein the random access message includes a second encryption of the identifier and an unencrypted portion of the identifier.14.The apparatus of claim 10, wherein the paging message includes an encryption of the identifier, and wherein the random access message is encrypted and is sent along with an unencrypted portion of the identifier.15.One or more computer-readable storage media storing instructions that, upon execution, cause operations comprising:sending, to an ambient Internet of Things (IoT) device, a paging message indicating an identifier of the ambient IoT device, the identifier protected in the paging message based on a first identifier protection procedure;receiving, from the ambient IoT device, a random access message indicating the identifier, the identifier protected in the random access message based on a second identifier protection procedure;verifying the identifier indicated in the random access message; andexchanging data with the ambient IoT device based on the verifying.16.The one or more computer-readable storage media of claim 15, wherein the identifier is associated with at least one of: a limited number of usage or a limited time duration for the usage, wherein the paging message includes the identifier.17.The one or more computer-readable storage media of claim 15, wherein the random access message includes the identifier and an index associated with the identifier.18.The one or more computer-readable storage media of claim 17, wherein the identifier is verified by at least determining a match between the index and a pre-stored index associated with the usage of the identifier, and wherein the operations further comprise:sending, to the ambient IoT device and subsequent to the random access message, an additional message that includes the index and the identifier.19.The one or more computer-readable storage media of claim 17, wherein the identifier, the index, and the random access message are a first identifier, a first index, and a first random access message, respectively, and wherein the operations further comprise:storing a first association between the first identifier and the first index and a second association between a second identifier of the ambient IoT device and a second index, wherein the first index is verified based on the first association;receiving, from the ambient IoT device, a second random access message that includes the second identifier and the second index; andverifying the second identifier based on the second association.20.The one or more computer-readable storage media of claim 17, wherein the identifier, the index, and the random access message are a first identifier, a first index, and a first random access message, respectively, and wherein the operations further comprise:receiving, from the ambient IoT device, a second random access message that includes a second identifier that is a hash of the first identifier and the second index; andverifying the second identifier based on the hash value and the index.

Images