Authentication for ambient internet of things (IOT) devices

Abstract

Disclosed are methods, systems, and computer-readable media to perform operations that include performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity including an AIoT Function (AIoTF), an AIoT Authentication Server Function (AUSF), and AIoT Unified Data Management (UDM), wherein the AIoT AUSF is an authentication anchor.

Description

AUTHENTICATION FOR AMBIENT INTERNET OF THINGS (IOT) DEVICESTECHNICAL FIELD

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

[0002] Wireless communication networks provide integrated communication platforms and telecommunication services to wireless user devices. Example telecommunication services include telephony, data (e.g., voice, audio, and / or video data) , messaging, and / or other services. The wireless communication networks have wireless access nodes that exchange wireless signals with the wireless user devices using wireless network protocols, such as protocols described in various telecommunication standards promulgated by the Third Generation Partnership Project (3GPP) . Example wireless communication networks include time-division multiple access (TDMA) networks, frequency-division multiple access (FDMA) networks, orthogonal frequency-division multiple access (OFDMA) networks, Long Term Evolution (LTE) , and Fifth Generation New Radio (5G NR) . The wireless communication networks facilitate mobile broadband service using technologies such as OFDM, multiple input multiple output (MIMO) , advanced channel coding, massive MIMO, beamforming, and / or other features.SUMMARY

[0003] According to one innovative aspect of the present disclosure, a method for wireless communication is disclosed. In one aspect, the method can include performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity including an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AIoT AUSF is an authentication anchor.

[0004] Other aspects include a user equipment (UE) such as an AIoT device, apparatuses, systems, and computer programs for performing the aforementioned method.

[0005] The innovative method can include other optional features. For example, in some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) including a random ID and the device ID; receiving from the reader a second message (Msg2) including the random ID; receiving, from the AIoTF, an authentication trigger message including the device ID and a Random Challenge (RAND) generated by the AIoT AUSF; determining a response (RES) using a key associated with the AIoT device, the device ID of the AIoT device and the RAND; preparing for transmission to the reader in an uplink Access Stratum (AS) service request message including the device ID, the RES, and a counter value; receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; and verifying the token to authenticate the control plane entity.

[0006] In some implementations, wherein performing the mutual authentication further includes: receiving from the reader the token in response to the reader transmitting an authentication request including the device ID, the RES, and the counter value to the AIoT AUSF through the AIoTF and a successful authentication of the AIoT device by the AIoT AUSF.

[0007] In some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; determining a response (RES) using a key associated with the AIoT device and the device ID of the AIoT device; receiving from the reader  a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and a counter value; and verifying the token to authenticate the control plane entity.

[0008] In some implementations, wherein performing the mutual authentication further includes: receiving from the reader the token in response to the reader transmitting an authentication request including the device ID, the RES, and a counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT AUSF.

[0009] In some implementations, wherein receiving the token determined by the AIoT UDM includes: determining, by the AIoT UDM, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value; comparing, by the AIoT AUSF, the XRES with the RES; and transmitting, by the AIoT AUSF, the token to the AIoT device through the AIoTF and the reader in response to the XRES matching with the RES.

[0010] In some implementations, wherein verifying the token to authenticate the control plane entity includes: determining an expected token using the key, the device ID, and the counter value; comparing the token with the expected token; and preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the control plane entity in response to the token matching with the expected token.

[0011] In some implementations, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, and the AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.

[0012] In some implementations, wherein the counter value is a sequential number or a random number.

[0013] According to another innovative aspect of the present disclosure, a method for wireless communication is disclosed. In one aspect, the method can include performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity including an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AIoT UDM is an authentication anchor.

[0014] Other aspects include a user equipment (UE) such as an AIoT device, apparatuses, systems, and computer programs for performing the aforementioned method.

[0015] The innovative method can include other optional features. For example, in some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) including a random ID; receiving from the reader a second message (Msg2) including the random ID; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission a third message (Msg3) including the device ID, the RES, and a counter value to the reader; receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; and verifying the token to authenticate the control plane entity.

[0016] In some implementations, wherein performing the mutual authentication includes: receiving from the reader the token in response to the reader transmitting an authentication request including the device ID, the RES, and the counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT UDM.

[0017] In some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission to the reader a first message (Msg1) including a random ID, the device ID, the RES, and a counter value; receiving from the reader a second message (Msg2) including the random ID; receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; and verifying the token to authenticate the control plane entity.

[0018] In some implementations, wherein performing the mutual authentication includes: receiving from the reader the token in response to the reader transmitting an authentication request including the device ID, the RES, and the counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT UDM.

[0019] In some implementations, receiving the token determined by the AIoT UDM includes: determining, by the AIoT UDM, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value; comparing, by the AIoT UDM,  the XRES with the RES; transmitting, by the AIoT UDM, the token to the AIoT device through the AIoT AUSF, the AIoTF and the reader in response to the XRES matching with the RES.

[0020] In some implementations, verifying the token to authenticate the control plane entity includes: determining an expected token using the key, the device ID, and the counter value; comparing the token with the expected token; in response to the token matching with the expected token, preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the control plane entity.

[0021] In some implementations, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, and the AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.

[0022] In some implementations, wherein the counter value is a sequential number or a random number.

[0023] According to another innovative aspect of the present disclosure, a method for wireless communication is disclosed. In one aspect, the method can include performing mutual authentication between an Ambient Internet of Things (AIoT) device and an Application Function (AF) through a control plane entity including an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AF manufactured the AIoT device, and the AF is an authentication anchor.

[0024] Other aspects include a user equipment (UE) such as an AIoT device, apparatuses, systems, and computer programs for performing the aforementioned method.

[0025] The innovative method can include other optional features. For example, in some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) including a random ID; receiving from the reader a second message (Msg2) including the random ID; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission to the reader a third message (Msg3) including the device ID, the RES, and a counter value; receiving from the reader a token, wherein the token is determined by the AF using the key, the device ID, and the counter value; and verifying the token to authenticate the AF.

[0026] In some implementations, wherein performing the mutual authentication includes: receiving from the reader the token in response to the reader transmitting an authentication request including the device ID, the RES, and the counter value to the AF through the AIoTF and a successful authentication of the AIoT device by the AF.

[0027] In some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission to the reader a first message (Msg1) including a random ID, the device ID, the RES, and a counter value; receiving from the reader a second message (Msg2) including the random ID; receiving from the reader a token, wherein the token is determined by the AF using the key, the device ID, and the counter value; and verifying the token to authenticate the AF.

[0028] In some implementations, wherein performing the mutual authentication includes: receiving from the reader the token in response to the reader transmitting an authentication request including the device ID, the RES, and the counter value to the AF through the AIoTF and a successful authentication of the AIoT device by the AF.

[0029] In some implementations, wherein performing the mutual authentication includes: receiving, from a reader associated with the AIoT device, a paging message including a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) including a random ID and the device ID; receiving from the reader a second message (Msg2) including the random ID; receiving, from the AIoTF, an authentication trigger message including the device ID and a Random Challenge (RAND) generated by the AF; determining a response (RES) using a key of the AIoT device, the device ID and the RAND; preparing for transmission to the reader in an uplink Access Stratum (AS) service request message including the device ID, the RES, and a counter value; receiving from the reader a token, wherein the token is determined by the AF using the key, the device ID, and the counter value; and verifying the token to authenticate the AF.

[0030] In some implementations, wherein performing the mutual authentication includes: receiving from the reader the token in response to the reader transmitting an authentication request  including the device ID, the RES, and the counter value to the AF through the AIoTF and a successful authentication of the AIoT device by the AIoT AF.

[0031] In some implementations, wherein receiving the token determined by the AF includes: determining, by the AF, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value; comparing, by the AF, the XRES with the RES; transmitting, by the AF, the token to the AIoT device through the AIoTF and the reader in response to the XRES matching with the RES.

[0032] In some implementations, wherein verifying the token to authenticate the AF includes: determining an expected token using the key, the device ID, and the counter value; comparing the token with the expected token; in response to the token matching with the expected token, preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the AF.

[0033] In some implementations, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, and the AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.

[0034] In some implementations, wherein the counter value is a sequential number or a random number.

[0035] According to another innovative aspect of the present disclosure, one or more processors including circuitry to execute one or more instructions that, when executed, cause the one or more processors to perform operations of the aforementioned method are disclosed.

[0036] According to another innovative aspect of the present disclosure, one or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations of the aforementioned method are disclosed.

[0037] The details of one or more embodiments of these systems and methods are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of these systems and methods will be apparent from the description and drawings, and from the claims.

[0038] BRIEF DESCRIPTION OF THE FIGURES

[0039] FIG. 1 illustrates a wireless network, according to some implementations.

[0040] FIG. 2 illustrates an example process of performing a control plane authentication with a 3-step RACH procedure, according to some implementations.

[0041] FIG. 3 illustrates an example process of performing a control plane authentication with a 2-step RACH procedure, according to some implementations.

[0042] FIG. 4 illustrates another example process of performing a control plane authentication with a 2-step RACH procedure, according to some implementations.

[0043] FIG. 5 illustrates an example process of performing a control plane authentication using a new Access Stratum (AS) message, according to some implementations.

[0044] FIG. 6 illustrates an example process of performing an application layer authentication with a 3-step RACH procedure, according to some implementations.

[0045] FIG. 7 illustrates an example process of performing an application layer authentication with a 2-step RACH procedure, according to some implementations.

[0046] FIG. 8 illustrates an example process of performing an application layer authentication using a new AS message, according to some implementations.

[0047] FIG. 9 illustrates another example process of performing a control plane authentication using a new AS message, according to some implementations.

[0048] FIG. 10 is a block diagram of an example UE, according to some implementations.

[0049] FIG. 11 is a block diagram of an example access node, according to some implementations.

[0050] FIG. 12 is a block diagram of an example apparatus, according to some implementations.

[0051] Like reference symbols in the various drawings indicate like elements.DETAILED DESCRIPTION

[0052] This disclosure describes methods and systems for mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a wireless communications network (e.g., a 3GPP cellular network) , or mutual authentication between an AIoT device and an Application Function (AF) that manufactured the AIoT device. The authentication anchor can be the control plane entity (e.g., AIoT Authentication Server Function (AUSF) or AIoT Unified Data Management (UDM) ) in the core network (CN) of the wireless network, or the AF. The authentication can be performed using a 2-step RACH procedure, a 3-step RACH procedure, or a new Access Stratum (AS) message.

[0053] FIG. 1 illustrates a wireless network 100, according to some implementations. The wireless network 100 includes a UE 102 and a base station 104 connected via one or more channels 106A, 106B across an air interface 108. The UE 102 and base station 104 communicate using a system that supports controls for managing the access of the UE 102 to a network via the base station 104. For example, the UE 102 can be an Ambient Internet of Things (AIoT) device 201 of FIGS. 2-8 and the base station 104 can be reader 203 of FIGS. 2-8.

[0054] In some implementations, the wireless network 100 may be a Non-Standalone (NSA) network that incorporates Long Term Evolution (LTE) and Fifth Generation (5G) New Radio (NR) communication standards as defined by the Third Generation Partnership Project (3GPP) technical specifications. For example, the wireless network 100 may be an E-UTRA (Evolved Universal Terrestrial Radio Access) -NR Dual Connectivity (EN-DC) network, or an NR-EUTRA Dual Connectivity (NE-DC) network. In some other implementations, the wireless network 100 may be a Standalone (SA) network that incorporates only 5G NR. Furthermore, other types of communication standards are possible, including future 3GPP systems (e.g., Sixth Generation (6G) ) , Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology (e.g., IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other present or future developed IEEE 802.11 technologies) , IEEE 802.16 protocols (e.g., WMAN, WiMAX, etc. ) , or the like. While aspects may be described herein using terminology commonly associated with 5G NR, aspects of the present disclosure can be applied to other systems, such as 3G, 4G, and / or systems subsequent to 5G (e.g., 6G) .

[0055] In the wireless network 100, the UE 102 and any other UE in the system may be, for example, any of laptop computers, smartphones, tablet computers, machine-type devices such as  smart meters or specialized devices for healthcare, intelligent transportation systems, or any other wireless device. In network 100, the base station 104 provides the UE 102 network connectivity to a broader network (not shown) . This UE 102 connectivity is provided via the air interface 108 in a base station service area provided by the base station 104. In some implementations, such a broader network may be a wide area network operated by a cellular network provider, or may be the Internet. Each base station service area associated with the base station 104 is supported by one or more antennas integrated with the base station 104. The service areas can be divided into a number of sectors associated with one or more particular antennas. Such sectors may be physically associated with one or more fixed antennas or may be assigned to a physical area with one or more tunable antennas or antenna settings adjustable in a beamforming process used to direct a signal to a particular sector.

[0056] The UE 102 includes control circuitry 110 coupled with transmit circuitry 112 and receive circuitry 114. The transmit circuitry 112 and receive circuitry 114 may each be coupled with one or more antennas. The control circuitry 110 may include various combinations of application-specific circuitry and baseband circuitry. The transmit circuitry 112 and receive circuitry 114 may be adapted to transmit and receive data, respectively, and may include radio frequency (RF) circuitry and / or front-end module (FEM) circuitry.

[0057] In various implementations, aspects of the transmit circuitry 112, receive circuitry 114, and control circuitry 110 may be integrated in various ways to implement the operations described herein. The control circuitry 110 may be adapted or configured to perform various operations, such as those described elsewhere in this disclosure related to a UE. For instance, the control circuitry 110 can estimate CSI in response to CSI-RS from the base station 104.

[0058] Additionally, the transmit circuitry 112 may transmit using a plurality of multiplexed uplink physical channels. The plurality of uplink physical channels may be multiplexed, e.g., according to time division multiplexing (TDM) or frequency division multiplexing (FDM) along with carrier aggregation. The transmit circuitry 112 may be configured to receive block data from the control circuitry 110 for transmission across the air interface 108.

[0059] The receive circuitry 114 may receive a plurality of multiplexed downlink physical channels from the air interface 108 and relay the physical channels to the control circuitry 110. The plurality of downlink physical channels may be multiplexed, e.g., according to TDM or FDM along with carrier aggregation. The transmit circuitry 112 and the receive circuitry 114 may  transmit and receive, respectively, both control data and content data (e.g., messages, images, video, etc. ) structured within data blocks that are carried by the physical channels.

[0060] FIG. 1 also illustrates the base station 104. In some implementations, the base station 104 may be a 5G radio access network (RAN) , a next-generation RAN, an E-UTRAN, a non-terrestrial cell, or a legacy RAN, such as a UTRAN. As used herein, the term “5G RAN” or the like may refer to the base station 104 that operates in an NR or 5G wireless network 100, and the term “E-UTRAN” or the like may refer to a base station 104 that operates in an LTE or 4G wireless network 100. The UE 102 utilizes connections (or channels) 106A, 106B, each of which includes a physical communications interface or layer.

[0061] The base station 104 circuitry may include control circuitry 116 coupled with transmit circuitry 118 and receive circuitry 120. The transmit circuitry 118 and receive circuitry 120 may each be coupled with one or more antennas that may be used to enable communications via the air interface 108. The transmit circuitry 118 and receive circuitry 120 may be adapted to transmit and receive data, respectively, to any UE connected to the base station 104. The receive circuitry 120 may receive a plurality of uplink physical channels from one or more UEs, including the UE 102.

[0062] In FIG. 1, the one or more channels 106A, 106B are illustrated as an air interface to enable communicative coupling, and can be consistent with cellular communications protocols, such as a UMTS protocol, a 3GPP LTE protocol, an Advanced long term evolution (LTE-A) protocol, a LTE-based access to unlicensed spectrum (LTE-U) , a 5G protocol, a NR protocol, an NR-based access to unlicensed spectrum (NR-U) protocol, and / or any other communications protocol (s) . In implementations, the UE 102 may directly exchange communication data via a ProSe interface. The ProSe interface may alternatively be referred to as a sidelink (SL) interface and may include one or more logical channels, including but not limited to a Physical Sidelink Control Channel (PSCCH) , a Physical Sidelink Discovery Channel (PSDCH) , and a Physical Sidelink Broadcast Channel (PSBCH) .

[0063] Authentication of AIoT devices

[0064] An AIoT device is an Internet of Things (IoT) device with limited energy storage capability and powered by energy harvesting. Energy harvesting allows the AIoT device to generate power from ambient sources such as solar, thermal, vibration, or radio frequency signals, which is useful in scenarios where conventional power sources or frequent battery replacements are impractical. Additional characteristics of an AIoT device are defined in 3GPP TR 38.769. Examples of energy  harvesting AIoT devices include smart sensors (e.g., environmental sensors that monitor conditions like temperature, humidity, or air quality) , wearable health monitors (e.g., devices that use body heat or motion for power, collecting and processing health data with onboard artificial intelligence (AI) to provide real-time monitoring) , structural health monitors (e.g., sensors embedded in buildings, bridges, or other structures that harvest energy from vibrations or light, and use AI to detect patterns indicating potential structural issues) , etc.

[0065] Application Function (AF) refers to a manufacturer that develops and produces AIoT devices. AF may also own a platform to manage the AIoT devices. Examples of AF include Samsung, Google, Amazon, Apple, Sony, Huawei, Bosch, Siemens, Philips, etc.

[0066] AIoT Function (AIoTF) refers to a new function in an operator domain for AIoT services, which is responsible for management, configuration, context storage, etc.

[0067] AIoT Unified Data Management (UDM) refers to UDM specifically for AIoT subscription storage. It can be collocated with conventional UDM within a network infrastructure (e.g., the AIoT UDM and the conventional UDM are situated in the same physical location or share the same physical infrastructure, even though they operate independently of each other) or operate as an independent entity. AIoT UDM has no interface with the conventional UDM, indicating a separation in functionality and data handling between the AIoT UDM and the conventional UDM.

[0068] AIoT Authentication Server Function (AUSF) refers to an authentication function for AIoT devices. AIoT AUSF can be collocated with conventional AUSF or operate as an independent entity. 5G primary authentication relies on a unique key stored in the Universal Subscriber Identity Module (USIM) and / or UDM for secure network access. In some examples, the AIoT device has a key serving as a root of trust, regardless of whether the device includes a Universal Integrated Circuit Card (UICC) or not.

[0069] In some implementations, the network-side anchor can be in the CN or in the AF, which correspond to different authentication processes. The network side anchor refers to a central or primary point in the network responsible for establishing and managing a trust relationship between one or more AIoT devices and the network. In some implementations, when the authentication anchor is located at CN, a control plane authentication can be performed. In some examples, AIoT UDM is used to store all the AIoT subscriptions. In some examples, the AIoT device and the AIoT UDM have a shared root key. In some examples, the authentication can be performed by the AIoT UDM or AIoT AUSF.

[0070] In some implementations, when the authentication anchor is located at AF, an application layer authentication can be performed. In some examples, AF has the authentication credentials (device IDs, root keys) of the AIoT devices. In some examples, AF is outside the Mobile Network Operator (MNO) domain. AF operates as an independent entity or service provider that interacts with the mobile network but is not managed or owned by the MNO (such as AT&T, Verizon, Vodafone, etc. ) . The MNO domain refers to the entire infrastructure, network components, services, and functions that an MNO owns, manages, and operates to provide mobile communication services. In some examples, AIoTF is implemented within the MNO domain. In some examples, AF can share authentication credentials generated by the AF with AIoTF.

[0071] Control Plane Authentication

[0072] In some implementations, a control plane authentication can be performed with a 3-step Random Access Channel (RACH) procedure. The control plane resides within a core network of a mobile communication system (such as 4G and 5G) and handles the signaling, management, and orchestration of network connections and services.

[0073] FIG. 2 illustrates an example process 200 of performing a control plane authentication with a 3-step RACH procedure, according to some implementations. The process 200 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 2) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In the process 200, AIoT UDM 209 serves as an authentication anchor.

[0074] At 202, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture. A root key is a fundamental cryptographic key that forms the basis of security and trust in a device, system, or network. It serves as the “root” or primary source of cryptographic material from which other keys and security mechanisms are derived. The device ID is a manufacturer-specific ID, uniquely identifying the AIoT device 201 within the network.

[0075] At 204, AIoT UDM 209 is configured with a copy of the key (AIoT UDM 209 and AIoT device 201 share the same key) as a second root key. In some examples, AIoT UDM 209 is the entity that owns the second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0076] At 206, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201. The AF 211 updates the AIoT UDM 209 with information about AIoT device  201 manufactured by the AF 211. This synchronization allows the AIoT UDM 209 to be aware of the identity of the AIoT device 201 and can manage subsequent interactions with the AIoT device 201.

[0077] At 208, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201. The type and format of ID are decided by Radio Access Network Working Group 2 (RAN2) . Reader 203 can be a network component, a base station (referred to as eNodeB in 4G LTE or gNodeB in 5G) , user equipment (such as a smartphone) , or an IoT gateway that facilitates communication between the network and the AIoT device 201.

[0078] At 210, AIoT device 201 transmits a first message (Msg1) including a random ID to reader 203. Msg1 is the random access preamble, and is the first message that the AIoT device 201 transmits to the reader 203 during a RACH procedure to signal its intent to access the network. The random ID included in this message is known as a Random Access Preamble Identifier. The random ID can identify the AIoT device 201’s request in the RACH procedure without revealing the permanent identity of the AIoT device 201.

[0079] At 212, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0080] At 214, AIoT device 201 calculates a response (RES) using the key and the device ID. In some implementations, the calculation involves a cryptographic function (such as a hash function or a cryptographic algorithm like Advanced Encryption Standard (AES) ) that combines the device’s key and the device ID. The RES is a cryptographic proof of identity. By including both the key and the device ID in the calculation, the RES serves as evidence that the AIoT device 201 possesses the correct credentials.

[0081] At 216, AIoT device 201 transmits the device ID, RES, and a counter value to reader 203 in the third message (Msg3) . The counter value can be generated as a random number or a sequential number that increases with each communication attempt. The inclusion of the counter value provides additional security by preventing replay attacks and maintaining synchronization between the AIoT device 201 and the network.

[0082] At 218-222, reader 203 transmits an authentication request to AIoT UDM 209 for authentication through AIoTF 205 and AIoT AUSF 207. The authentication request includes the device ID, RES, and the counter value.

[0083] At 224, AIoT UDM 209 calculates an Expected Response (XRES) using the same algorithm as the RES and then compares RES with XRES. If RES is equal to XRES, the authentication of AIoT device 201 is successful. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails and AIoT UDM 209 terminates the process 200. AIoT UDM 209 also calculates a token to be used for network authentication.

[0084] In some implementations, RES / XRES and the token can be calculated using the same function but with different parameters. For example, RES / XRES = Function_K (device ID, RAND) ; Token = Function_K (device ID, Counter) . Random Challenge (RAND) is a random number or nonce generated by the network during the authentication process. Its primary purpose is to introduce randomness into the calculation, ensuring that each authentication attempt results in a unique RES. The use of RAND helps prevent replay attacks, as a new challenge is issued each time the device attempts to authenticate. In some examples, Function_K can be a Key Derivation Function (KDF) , as specified in 3GPP TS 33.220. A KDF is a cryptographic algorithm that takes a root key, device ID, and RAND to generate a derived RES or XRES. In some implementations, the derived RES or XRES has 256 bits. In some examples, Function_K can be a HASH function. A hash function can take parameters such as the root key, device ID, and random challenge to produce a fixed-size RES or XRES. In some examples, Function_K can be HASH (KDF (device ID) ) . Function_K can be a combination of both a KDF and a HASH function. This hybrid approach adds an extra layer of security and flexibility to the authentication process. In some examples, if the length of RES / XRES or token is limited, the output of Function_K can be truncated. The length of Msg3 is decided by RAN1 / 2 working groups.

[0085] At 226-230, AIoT UDM 209 transmits the authentication response including the token to reader 203 through AIoTF 205 and AIoT AUSF 207.

[0086] At 232, If the authentication of AIoT device 201 is successful, reader 203 continues with the subsequent messages at 234-238. If the authentication of AIoT device 201 fails, reader 203 terminates process 200.

[0087] At 234, reader 203 transmits the token to AIoT device 201 in a downlink (DL) command message.

[0088] At 236, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 224 and then compares the token with the expected token. If the token is equal to the expected token, the network authentication is successful. Otherwise, if the token is different from the expected token, the authentication of the network fails, and the AIoT device 201 terminates the process 200.

[0089] At 238, if the authentication of the network is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0090] FIG. 3 illustrates an example process 300 of performing a control plane authentication with a 2-step RACH procedure, according to some implementations. The process 300 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 3) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In the process 300, AIoT UDM 209 serves as an authentication anchor.

[0091] At 302, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture.

[0092] At 304, AIoT UDM 209 is configured with a copy of the key as a second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0093] At 306, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201.

[0094] At 308, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201.

[0095] At 310, AIoT device 201 calculates a response (RES) using the key and the device ID.

[0096] At 312, AIoT device 201 transmits a first message (Msg1) including a random ID, the device ID, RES, and a counter value to reader 203. The counter value can be generated as a random number or a sequence number that increases with each communication attempt.

[0097] At 314, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0098] At 316-320, reader 203 transmits an authentication request to AIoT UDM 209 for authentication through AIoTF 205 and AIoT AUSF 207. The authentication request includes the device ID, RES, and the counter value.

[0099] At 322, AIoT UDM 209 calculates an Expected Response (XRES) using the same algorithm as the RES and then compares RES with XRES. If RES is equal to XRES, the authentication of AIoT device 201 is successful. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails. AIoT UDM 209 also calculates a token to be used for network authentication.

[0100] At 324-328, AIoT UDM 209 transmits the authentication response including the token to the reader 203 through AIoTF 205 and AIoT AUSF 207.

[0101] At 330, if the authentication is successful, the reader 203 continues with the subsequent messages at 332-336. If the authentication fails, the reader 203 terminates the process 300.

[0102] At 332, reader 203 transmits the token to AIoT device 201 in a downlink (DL) command message.

[0103] At 334, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 324 and then compares the token with the expected token. If the token is equal to the expected token, the network authentication is successful. Otherwise, if the token is different from the expected token, the authentication of the network fails and the AIoT device 201 terminates the process 300.

[0104] At 336, if the authentication of the network is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0105] FIG. 4 illustrates another example process 400 of performing a control plane authentication with a 2-step RACH procedure, according to some implementations. The process 400 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 3) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In the process 400, AIoT AUSF 207 serves as an authentication anchor.

[0106] At 402, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture.

[0107] At 404, AIoT UDM 209 is configured with a copy of the key as a second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0108] At 406, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201.

[0109] At 408, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201.

[0110] At 410, AIoT device 201 calculates a response (RES) using the key and the device ID.

[0111] At 412, AIoT device 201 transmits a first message (Msg1) including a random ID, the device ID, RES, and a counter value to reader 203. The counter value can be generated as a random number or a sequence number that increases with each communication attempt.

[0112] At 414, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0113] At 416-418, reader 203 transmits an authentication request to AIoT AUSF 207 for authentication through AIoTF 205. The authentication request includes the device ID, RES, and the counter value.

[0114] At 420, AIoT AUSF 207 transmits an authentication request to AIoT UDM 209 including the device ID and the counter value.

[0115] At 422, AIoT UDM 209 calculates XRES and a token and transmits an authentication response including XRES and the token to AIoT AUSF 207. AIoT UDM 209 calculates XRES using the same algorithm as the RES.

[0116] At 424, AIoT AUSF 207 compares XRES with RES. If RES is equal to XRES, the authentication of AIoT device 201 is successful and AIoT AUSF 207 transmits the token to reader 203. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails, and the AIoT AUSF 207 terminates the process 400.

[0117] At 426-428, AIoT UDM 209 transmits the authentication response including the token to reader 203 through AIoTF 205 and AIoTF 207.

[0118] At 430, if the authentication of AIoT device 201 is successful, reader 203 continues with the subsequent messages at 432-436. If the authentication of AIoT device 201 fails, reader 203 terminates the process 400.

[0119] At 432, reader 203 transmits the token to AIoT device 201 in a downlink (DL) command message.

[0120] At 434, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 324 and then compares the token with the expected token. If the token is equal to the expected token, the network  authentication is successful. Otherwise, if the token is different from the expected token, the network authentication fails and the AIoT device 201 terminates the process 400.

[0121] At 436, if the authentication of the network is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0122] FIG. 5 illustrates an example process 500 of performing a control plane authentication using a new AS message, according to some implementations. The process 500 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 3) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In the process 500, AIoT AUSF 207 serves as an authentication anchor. An AS message is a communication message exchanged between the User Equipment (UE) (e.g., AIoT device 201) and the Radio Access Network (RAN) , such as the base station (e.g., reader 203) .

[0123] At 502, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture.

[0124] At 504, AIoT UDM 209 is configured with a copy of the key as a second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0125] At 506, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201.

[0126] At 508, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201.

[0127] At 510, AIoT device 201 transmits a first message (Msg1) including a random ID and the device ID to reader 203.

[0128] At 512, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0129] At 514, reader 203 transmits a feedback message to AIoTF 205 if the RACH procedure is successful. The feedback message is referred to as the inventory response that includes information indicating that the AIoT device 201 has been successfully identified and added to the network inventory.

[0130] At 516, AIoTF 205 notifies AIoT AUSF 207 to trigger an authentication when the paging is successful. AIoT AUSF 207 generates a RAND and transmits the RAND to AIoTF 205 to trigger the authentication.

[0131] At 518, AIoTF 205 transmits an authentication trigger message, including the device ID and RAND generated by AIoT AUSF 207 at 516.

[0132] At 520, AIoT device 201 calculates a RES using the key, device ID, and RAND.

[0133] At 522, AIoT device 201 transmits the device ID, RES, and counter value to reader 203 in an uplink AS service request message. The AS message is decided by Service and System Aspects Working Group 2 (SA2) .

[0134] At 524-526, reader 203 transmits an authentication request to AIoT AUSF 207 for authentication through AIoTF 205. The authentication request includes the device ID, RES, and the counter value.

[0135] At 528, AIoT AUSF 207 transmits an authentication request to AIoT UDM 209 including the device ID and the counter value.

[0136] At 530, AIoT UDM 209 calculates XRES and a token and transmits an authentication response including XRES and the token to AIoT AUSF 207. AIoT UDM 209 calculates XRES using the same algorithm as the RES.

[0137] At 532, AIoT AUSF 207 compares XRES with RES. If RES is equal to XRES, the authentication of AIoT device 201 is successful and AIoT AUSF 207 transmits the token to reader 203. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails, and the AIoT AUSF 207 terminates the process 500.

[0138] At 534-536, AIoT UDM 209 transmits the authentication response including the token to reader 203 through AIoTF 205 and AIoTF 207.

[0139] At 538, if the authentication of AIoT device 201 is successful, reader 203 continues with the subsequent messages at 540-544. If the authentication of AIoT device 201 fails, reader 203 terminates the process 500.

[0140] At 540, reader 203 transmits the token to AIoT device 201 in a DL command message.

[0141] At 542, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 324 and then compares the token with the expected token. If the token is equal to the expected token, the network  authentication is successful. Otherwise, if the token is different from the expected token, the authentication of the network fails and the AIoT device 201 terminates the process 500.

[0142] At 544, if the authentication of the network is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0143] Application Layer Authentication

[0144] In some implementations, Application layer authentication can be performed with a 3-Step RACH procedure, according to some implementations. FIG. 6 illustrates an example process 600 of performing an application layer authentication with a 3-step RACH procedure, according to some implementations. The process 600 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 6) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In process 600, AF 211 serves as an authentication anchor. AF 211 is an external entity that develops one or more AIoT devices 201 and software applications that interact with the network.

[0145] At 602, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture.

[0146] At 604, AIoT UDM 209 is configured with a copy of the key as a second root key. In some examples, AIoT UDM 209 is the entity that owns the second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0147] At 606, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201.

[0148] At 608, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201.

[0149] At 610, AIoT device 201 transmits a first message (Msg1) including a random ID to reader 203.

[0150] At 612, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0151] At 614, AIoT device 201 calculates a response (RES) using the key and the device ID. In some implementations, the calculation involves a cryptographic function (such as a hash function  or a cryptographic algorithm like Advanced Encryption Standard (AES) ) that combines the device’s key and the device ID.

[0152] At 616, AIoT device 201 transmits the device ID, RES, and a counter value to reader 203 in the third message (Msg3) . The counter value can be generated as a random number or a sequence number that increases with each communication attempt. The inclusion of the counter value provides additional security by preventing replay attacks and maintaining synchronization between the AIoT device 201 and the network.

[0153] At 618, reader 203 transmits an authentication request to AIoTF 205 for authentication. The authentication request includes the device ID, RES, and the counter value.

[0154] At 620, AIoTF 205 transmits the authentication request including the device ID, RES, and the counter value to AF 211 directly. An interface between AIoTF 205 and AF 211 to support the direct message delivery is defined by SA2.

[0155] At 622, AF 211 calculates an Expected Response (XRES) using the same algorithm as the RES and then compares RES with XRES. If RES is equal to XRES, the authentication of AIoT device 201 is successful. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails and AF 211 terminates the process 200. AF 211 also calculates a token to be used for network authentication.

[0156] At 624-626, AF 211 transmits an authentication response including the token to reader 203 through AIoTF 205.

[0157] At 628, if the authentication of AIoT device 201 is successful, reader 203 continues with the subsequent messages at 630-634. If the authentication of AIoT device 201 fails, reader 203 terminates the process 600.

[0158] At 630, reader 203 transmits the token to AIoT device 201 in a downlink (DL) command message.

[0159] At 632, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 622 and then compares the token with the expected token. If the token is equal to the expected token, the authentication of the AF is successful. Otherwise, if the token is different from the expected token, the authentication of the AF fails, and the AIoT device 201 terminates the process 600.

[0160] At 634, if the authentication of the AF is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0161] In some implementations, Application layer authentication can be performed with a 2-step RACH procedure, according to some implementations. FIG. 7 illustrates an example process 700 of performing an application layer authentication with a 2-step RACH procedure, according to some implementations. The process 700 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 7) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In the process 700, AF 211 serves as an authentication anchor. AF 211 is an external entity that develops one or more AIoT devices 201 and software applications that interact with the network.

[0162] At 702, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture.

[0163] At 704, AIoT UDM 209 is configured with a copy of the key as a second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0164] At 706, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201.

[0165] At 708, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201.

[0166] At 710, AIoT device 201 calculates a response (RES) using the key and the device ID.

[0167] At 712, AIoT device 201 transmits a first message (Msg1) including a random ID, the device ID, RES, and a counter value to reader 203. The counter value can be generated as a random number or a sequence number that increases with each communication attempt.

[0168] At 714, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0169] At 716, reader 203 transmits an authentication request to AIoTF 205 for authentication. The authentication request includes the device ID, RES, and the counter value.

[0170] At 718, AIoTF 205 transmits the authentication request including the device ID, RES, and the counter value to AF 211 directly. An interface between AIoTF 205 and AF 211 to support the direct message delivery is defined by SA2.

[0171] At 720, AF 211 calculates an Expected Response (XRES) using the same algorithm as the RES and then compares RES with XRES. If RES is equal to XRES, the authentication of AIoT  device 201 is successful. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails and AF 211 terminates the process 200. AF 211 also calculates a token to be used for network authentication.

[0172] At 722-724, AF 211 transmits an authentication response including the token to reader 203 through AIoTF 205.

[0173] At 726, if the authentication of AIoT device 201 is successful, reader 203 continues with the subsequent messages at 728-732. If the authentication of AIoT device 201 fails, reader 203 terminates process 700.

[0174] At 728, reader 203 transmits the token to AIoT device 201 in a downlink (DL) command message.

[0175] At 730, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 720 and then compares the token with the expected token. If the token is equal to the expected token, the authentication of the AF is successful. Otherwise, if the token is different from the expected token, the authentication of the AF fails, and the AIoT device 201 terminates process 700.

[0176] At 732, if the authentication of the AF is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0177] In some implementations, Application layer authentication can be performed using a new AS message, according to some implementations. FIG. 8 illustrates an example process 800 of performing an application layer authentication using a new AS message, according to some implementations. The process 800 can be modified or reconfigured to include additional, fewer, or different steps (not shown in FIG. 8) , which can be performed in the order shown or in a different order. AIoTF 205, AIoT AUSF 207, and AIoT UDM 209 are placed in control plane entity 213. In process 800, AF 211 serves as an authentication anchor. AF 211 is an external entity that develops one or more AIoT devices 201 and software applications that interact with the network.

[0178] At 802, AIoT device 201 is configured with a device ID and a key as a first root key at the time of manufacture.

[0179] At 804, AIoT UDM 209 is configured with a copy of the key as a second root key. The second root key is cryptographically linked to the first root key of AIoT device 201.

[0180] At 806, the AF 211 synchronizes the device ID with AIoT UDM 209 after manufacturing AIoT device 201.

[0181] At 808, reader 203 transmits a paging message including a device ID to the AIoT device 201 to notify or wake up the AIoT device 201.

[0182] At 810, AIoT device 201 transmits a first message (Msg1) including a random ID and the device ID to reader 203.

[0183] At 812, reader 203 echoes back the random ID in the second message (Msg2) to acknowledge the AIoT device 201’s initial request by including the same random ID received in the first message (Msg1) .

[0184] At 814, reader 203 transmits a feedback message to AIoTF 205 if the RACH procedure is successful. The feedback message is referred to as the inventory response that includes information indicating that the AIoT device 201 has been successfully identified and added to the network inventory.

[0185] At 816, AIoTF 205 notifies AF 211 to trigger an authentication when the paging is successful. AF 211 generates a RAND and transmits the RAND to AIoTF 205 to trigger the authentication.

[0186] At 818, AIoTF 205 transmits an authentication trigger message, including the device ID and RAND generated by AF 211 at 816.

[0187] At 820, AIoT device 201 calculates a RES using the key, device ID, and RAND.

[0188] At 822, AIoT device 201 transmits the device ID, RES, and counter value to reader 203 in an uplink AS service request message. The AS message is decided by Service and System Aspects Working Group 2 (SA2) .

[0189] At 824, reader 203 transmits an authentication request to AIoTF 205 for authentication. The authentication request includes the device ID, RES, and the counter value.

[0190] At 826, AIoTF 205 transmits the authentication request including the device ID, RES, and the counter value to AF 211 directly. An interface between AIoTF 205 and AF 211 to support the direct message delivery is defined by SA2.

[0191] At 828, AF 211 calculates an Expected Response (XRES) using the same algorithm as the RES and then compares RES with XRES. If RES is equal to XRES, the authentication of AIoT device 201 is successful. Otherwise, if RES is different from XRES, the authentication of AIoT device 201 fails and AF 211 terminates the process 200. AF 211 also calculates a token to be used for network authentication.

[0192] At 830-832, AF 211 transmits an authentication response including the token to reader 203 through AIoTF 205.

[0193] At 834, if the authentication of AIoT device 201 is successful, reader 203 continues with the subsequent messages at 728-732. If the authentication of AIoT device 201 fails, reader 203 terminates process 800.

[0194] At 836, reader 203 transmits the token to AIoT device 201 in a downlink (DL) command message.

[0195] At 838, AIoT device 201 verifies if the token is correct. AIoT device 201 calculates an expected token using the same algorithm as the token calculated at 828 and then compares the token with the expected token. If the token is equal to the expected token, the authentication of the AF is successful. Otherwise, if the token is different from the expected token, the authentication of the AF fails, and the AIoT device 201 terminates process 700.

[0196] At 840, if the authentication of the AF is successful, the AIoT device 201 replies with an uplink (UL) message to reader 203 notifying successful authentication.

[0197] FIG. 9 illustrates another example process 900 of performing a control plane authentication using a new AS message, according to some implementations. The process 900 is described as being performed by a UE, such as AIoT device 201, UE 102 of FIG. 1, or UE 1000 of FIG. 10 that is described in the following sections. The process 900 can be modified or reconfigured to include additional, fewer, or different steps, which can be performed in the order shown or in a different order.

[0198] At 902, AIoT device (e.g., AIoT device 201) receives, from a reader (reader 203) associated with the AIoT device, a paging message including a device ID of the AIoT device. The reader interfaces with one or more of the AIoTF, AUSF, or AIoT UDM in the control plane (e.g., control plane entity 213) .

[0199] At 904, AIoT device transmits to the reader a first message (Msg1) including a random ID and the device ID.

[0200] At 906, AIoT device receives from the reader a second message (Msg2) including the random ID.

[0201] At 908, AIoT device receives, from the AIoTF (e.g., AIoTF 205) , an authentication trigger message including the device ID and a RAND generated by the AIoT AUSF (e.g., AIoT AUSF 207) .

[0202] At 910, AIoT device determines a response (RES) using a key of the AIoT device, the device ID and the RAND.

[0203] At 912, AIoT device transmits to the reader in an uplink AS service request message including the device ID, the RES, and a counter value indicating a number of communication attempts.

[0204] At 914, AIoT device receives from the reader a token determined by the AIoT UDM (e.g., AIoT UDM 209) using the key, the device ID, and the counter value in response to the reader transmitting an authentication request including the device ID, the RES, and the counter value to the AIoT AUSF through the AIoTF and a successful authentication of the AIoT device by the AIoT AUSF.

[0205] At 916, AIoT device verifies the token to authenticate the control plane entity.

[0206] FIG. 10 illustrates an example UE 1000, according to some implementations. The UE 1000 may be similar to and substantially interchangeable with UE 102 of FIG. 1.

[0207] The UE 1000 may be any mobile or non-mobile computing device, such as, for example, mobile phones, computers, tablets, industrial wireless sensors (for example, microphones, pressure sensors, thermometers, motion sensors, accelerometers, inventory sensors, electric voltage / current meters, etc. ) , video devices (for example, cameras, video cameras, etc. ) , wearable devices (for example, a smartwatch) , relaxed-IoT devices.

[0208] The UE 1000 may include processor circuitry 1002, RF interface circuitry 1004, memory / storage 1006, user interface 1008, sensors 1010, driver circuitry 1012, power management integrated circuit (PMIC) 1014, one or more antenna (s) 1016, and battery 1018. The components of the UE 1000 may be implemented as integrated circuits (ICs) , portions thereof, discrete electronic devices, or other modules, logic, hardware, software, firmware, or a combination thereof. The block diagram of FIG. 10 is intended to show a high-level view of some of the components of the UE 1000. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0209] The components of the UE 1000 may be coupled with various other components over one or more interconnects 1020, which may represent any type of interface, input / output, bus (local, system, or expansion) , transmission line, trace, optical connection, etc., that allows various circuit components (on common or different chips or chipsets) to interact with one another.

[0210] The processor circuitry 1002 may include processor circuitry such as, for example, baseband processor circuitry (BB) 1022A, central processor unit circuitry (CPU) 1022B, and graphics processor unit circuitry (GPU) 1022C. The processor circuitry 1002 may include any type of circuitry, or processor circuitry that executes or otherwise operates computer-executable instructions, such as program code, software modules, or functional processes from memory / storage 1006 to cause the UE 1000 to perform operations as described herein.

[0211] In some implementations, the baseband processor circuitry 1022A may access a communication protocol stack 1024 in the memory / storage 1006 to communicate over a 3GPP-compatible network. In general, the baseband processor circuitry 1022A may access the communication protocol stack to: perform user plane functions at a physical (PHY) layer, medium access control (MAC) layer, radio link control (RLC) layer, packet data convergence protocol (PDCP) layer, service data adaptation protocol (SDAP) layer, and PDU layer; and perform control plane functions at a PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and a non-access stratum layer. In some implementations, the PHY layer operations may additionally / alternatively be performed by the components of the RF interface circuitry 1004. The baseband processor circuitry 1022A may generate or process baseband signals or waveforms that carry information in 3GPP-compatible networks. In some implementations, the waveforms for NR may be based on cyclic prefix orthogonal frequency division multiplexing (OFDM) “CP-OFDM” in the uplink or downlink, and discrete Fourier transform spread OFDM “DFT-S-OFDM” in the uplink.

[0212] The memory / storage 1006 may include one or more non-transitory, computer-readable media that include instructions (for example, communication protocol stack 1024) that may be executed by one or more of the processor circuitry 1002 to cause the UE 1000 to perform various operations described herein. The memory / storage 1006 includes any type of volatile or non-volatile memory that may be distributed throughout the UE 1000. In some implementations, some of the memory / storage 1006 may be located on the processor circuitry 1002 itself (for example, L1 and L2 cache) , while other memory / storage 1006 is external to the processor circuitry 1002 but accessible thereto via a memory interface. The memory / storage 1006 may include any suitable volatile or non-volatile memory such as, but not limited to, dynamic random access memory (DRAM) , static random access memory (SRAM) , erasable programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) , Flash memory, solid-state memory, or any other type of memory device technology.

[0213] The RF interface circuitry 1004 may include transceiver circuitry and a radio frequency front module (RFEM) that allows the UE 1000 to communicate with other devices over a radio access network. The RF interface circuitry 1004 may include various elements arranged in transmit or receive paths. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuitry, control circuitry, etc.

[0214] In the receive path, the RFEM may receive a radiated signal from an air interface via antenna (s) 1016 and proceed to filter and amplify (with a low-noise amplifier) the signal. The signal may be provided to a receiver of the transceiver that downconverts the RF signal into a baseband signal that is provided to the baseband processor of the processor circuitry 1002.

[0215] In the transmit path, the transmitter of the transceiver up-converts the baseband signal received from the baseband processor and provides the RF signal to the RFEM. The RFEM may amplify the RF signal through a power amplifier prior to the signal being radiated across the air interface via the antenna (s) 1016. In various implementations, the RF interface circuitry 1004 may be configured to transmit / receive signals in a manner compatible with NR access technologies.

[0216] The antenna (s) 1016 may include one or more antenna elements to convert electrical signals into radio waves to travel through the air and to convert received radio waves into electrical signals. The antenna elements may be arranged into one or more antenna panels. The antenna (s) 1016 may have antenna panels that are omnidirectional, directional, or a combination thereof to enable beamforming and multiple input, multiple output communications. The antenna (s) 1016 may include microstrip antennas, printed antennas fabricated on the surface of one or more printed circuit boards, patch antennas, phased array antennas, etc. The antenna (s) 1016 may have one or more panels designed for specific frequency bands including bands in FR1 or FR2.

[0217] The user interface 1008 includes various input / output (I / O) devices designed to enable user interaction with the UE 1000. The user interface 1008 includes input device circuitry and output device circuitry. Input device circuitry includes any physical or virtual means for accepting an input including, inter alia, one or more physical or virtual buttons (for example, a reset button) , a physical keyboard, keypad, mouse, touchpad, touchscreen, microphones, scanner, headset, or the like. The output device circuitry includes any physical or virtual means for showing information or otherwise conveying information, such as sensor readings, actuator position (s) , or other like information. Output device circuitry may include any number or combinations of audio or visual displays, including, inter alia, one or more simple visual outputs / indicators (for example, binary  status indicators such as light emitting diodes “LEDs” and multi-character visual outputs) , or more complex outputs such as display devices or touchscreens (for example, liquid crystal displays “LCDs, ” LED displays, quantum dot displays, projectors, etc. ) , with the output of characters, graphics, multimedia objects, and the like being generated or produced from the operation of the UE 1000.

[0218] The sensors 1010 may include devices, modules, or subsystems whose purpose is to detect events or changes in their environment and send the information (sensor data) about the detected events to some other device, module, subsystem, etc. Examples of such sensors include, inter alia, inertia measurement units including accelerometers, gyroscopes, or magnetometers; microelectromechanical systems or nanoelectromechanical systems including 3-axis accelerometers, 3-axis gyroscopes, or magnetometers; level sensors; temperature sensors (for example, thermistors) ; pressure sensors; image capture devices (for example, cameras or lensless apertures) ; light detection and ranging sensors; proximity sensors (for example, infrared radiation detector and the like) ; depth sensors; ambient light sensors; ultrasonic transceivers; microphones or other like audio capture devices; etc.

[0219] The driver circuitry 1012 may include software and hardware elements that operate to control particular devices that are embedded in the UE 1000, attached to the UE 1000, or otherwise communicatively coupled with the UE 1000. The driver circuitry 1012 may include individual drivers allowing other components to interact with or control various input / output (I / O) devices that may be present within, or connected to, the UE 1000. For example, driver circuitry 1012 may include a display driver to control and allow access to a display device, a touchscreen driver to control and allow access to a touchscreen interface, sensor drivers to obtain sensor readings of sensors 1010 and control and allow access to sensors 1010, drivers to obtain actuator positions of electro-mechanic components or control and allow access to the electro-mechanic components, a camera driver to control and allow access to an embedded image capture device, audio drivers to control and allow access to one or more audio devices.

[0220] The PMIC 1014 may manage power provided to various components of the UE 1000. In particular, with respect to the processor circuitry 1002, the PMIC 1014 may control power-source selection, voltage scaling, battery charging, or DC-to-DC conversion.

[0221] In some implementations, the PMIC 1014 may control, or otherwise be part of, various power-saving mechanisms of the UE 1000. A battery 1018 may power the UE 1000, although in  some examples the UE 1000 may be mounted deployed in a fixed location, and may have a power supply coupled to an electrical grid. The battery 1018 may be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, and the like. In some implementations, such as in vehicle-based applications, the battery 1018 may be a typical lead-acid automotive battery.

[0222] FIG. 11 illustrates an example access node 1100 (e.g., a base station or gNB) , according to some implementations. The access node 1100 may be similar to and substantially interchangeable with base station 104. The access node 1100 may include processor circuitry 1102, RF interface circuitry 1104, CN interface circuitry 1106, memory / storage circuitry 1108, and one or more antenna (s) 1110.

[0223] The components of the access node 1100 may be coupled with various other components over one or more interconnects 1112. The processor circuitry 1102, RF interface circuitry 1104, memory / storage circuitry 1108 (including communication protocol stack 1114) , antenna (s) 1110, and interconnects 1112 may be similar to like-named elements shown and described with respect to FIG. 10. For example, the processor circuitry 1102 may include processor circuitry such as, for example, baseband processor circuitry (BB) 1116A, central processor unit circuitry (CPU) 1116B, and graphics processor unit circuitry (GPU) 1116C.

[0224] The CN interface circuitry 1106 may provide connectivity to a core network, for example, a 5th 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 access node 1100 via a fiber optic or wireless backhaul. The CN interface circuitry 1106 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 1106 may include multiple controllers to provide connectivity to other networks using the same or different protocols.

[0225] As used herein, the terms “access node, ” “access point, ” or the like may describe equipment that provides the radio baseband functions for data and / or voice connectivity between a network and one or more users. These access nodes can be referred to as BS, gNBs, RAN nodes, eNBs, NodeBs, RSUs, TRxPs or TRPs, and so forth, and can include ground stations (e.g., terrestrial access points) or satellite stations providing coverage within a geographic area (e.g., a cell) . As used herein, the term “NG RAN node” or the like may refer to an access node 1100 that operates  in an NR or 5G system (for example, a gNB) , and the term “E-UTRAN node” or the like may refer to an access node 1100 that operates in an LTE or 4G system (e.g., an eNB) . According to various implementations, the access node 1100 may be implemented as one or more of a dedicated physical device such as a macrocell base station, and / or a low power (LP) base station for providing femtocells, picocells or other like cells having smaller coverage areas, smaller user capacity, or higher bandwidth compared to macrocells.

[0226] In some implementations, all or parts of the access node 1100 may be implemented as one or more software entities running on server computers as part of a virtual network, which may be referred to as a CRAN and / or a virtual baseband unit pool (vBBUP) . In these implementations, the CRAN or vBBUP may implement a RAN function split, such as a PDCP split wherein RRC and PDCP layers are operated by the CRAN / vBBUP and other L2 protocol entities are operated by the access node 1100; a MAC / PHY split wherein RRC, PDCP, RLC, and MAC layers are operated by the CRAN / vBBUP and the PHY layer is operated by the access node 1100; or a “lower PHY” split wherein RRC, PDCP, RLC, MAC layers and upper portions of the PHY layer are operated by the CRAN / vBBUP and lower portions of the PHY layer are operated by the access node 1100.

[0227] In V2X scenarios, the access node 1100 may be or act as RSUs. The term “RoadSide Unit” or “RSU” may refer to any transportation infrastructure entity used for V2X communications. An RSU may be implemented in or by a suitable RAN node or a stationary (or relatively stationary) UE, where an RSU implemented in or by a UE may be referred to as a “UE-type RSU, ” an RSU implemented in or by an eNB may be referred to as an “eNB-type RSU, ” an RSU implemented in or by a gNB may be referred to as a “gNB-type RSU, ” and the like.

[0228] FIG. 12 is a block diagram of an example apparatus 1200, according to some implementations. In some implementations, the apparatus 1200 includes a baseband processor circuitry. For example, the apparatus 1200 may be similar to the baseband processor circuitry (BB) 1022A of FIG. 10 or the baseband processor circuitry (BB) 1116A of FIG. 11 in some cases.

[0229] As shown, the apparatus 1200 includes one or more processors 1216 (processor 1216A, processor 1216B, etc. ) , and memory / storage 1208 storing instructions 1214 that are executed by the one or more processors 1216A and 1216B. Although FIG. 12 illustrates the apparatus 1200 as having multiple processors, in some cases the apparatus 1200 can include a single processor (e.g., one of processor 1216A or processor 1216B) .

[0230] The apparatus 1200 is electrically and communicatively coupled, through RF interface 1212, to RF circuitry 1204 and associated antenna structure 1210. In some implementations, one or more of the processors 1216A and 1216B execute the instructions 1214 to control communications through the RF circuitry 1204 and antenna structure 1210. For example, the one or more processors 1216A and 1216B may execute the instructions 1214 to generate or process baseband signals or waveforms that carry information using wireless channels, and / or manage the radio functions of RF circuitry 1204 and antenna structure 1210, such as signal modulation, encoding, radio frequency shifting, in addition or as an alternative to the user plane or control plane functions as described with respect to the baseband processor circuitry (BB) 1022A of FIG. 10 and the baseband processor circuitry (BB) 1116A of FIG. 11. In doing so, the apparatus 1200 enables communication, e.g., wireless cellular communication, over a 3GPP compatible network.

[0231] Additionally, in some implementations, the apparatus 1200 may include wireless hardware connectivity interface (s) to send / receive data to / from Near Field Communication (NFC) components,  components (e.g.,  Low Energy) ,  components, and other communication components, and a power management interface (e.g., an interface to send / receive power) . In such implementations, the instructions 1214 may include instructions that, when executed by one or more of the processors 1216A and 1216B, cause these processors to perform Wi-Fi communications on an 802.11 network, and / or perform Bluetooth communications.

[0232] In some implementations, one or more of the processor 1216A and the processor 1216B can be a 3G baseband processor, a 4G baseband processor, a 5G baseband processor, or other suitable baseband processor. In some implementations, one or more of the processors 1216A and 1216B may be configured as an FPGA (Field Programmable Gate Array) , and / or may have dedicated hardware components, which may include an ASIC (Application Specific Integrated Circuit) .

[0233] Examples

[0234] Example 1: A method for wireless communication, the method comprising: performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity comprising an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AIoT AUSF is an authentication anchor.

[0235] Example 2: The method of Example 1, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) comprising a random ID and the device ID; receiving from the reader a second message (Msg2) comprising the random ID; receiving, from the AIoTF, an authentication trigger message comprising the device ID and a Random Challenge (RAND) generated by the AIoT AUSF; determining a response (RES) using a key associated with the AIoT device, the device ID of the AIoT device and the RAND; preparing for transmission to the reader in an uplink Access Stratum (AS) service request message comprising the device ID, the RES, and a counter value; receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; and verifying the token to authenticate the control plane entity.

[0236] Example 3: The method of Example 2, wherein performing the mutual authentication further comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the AIoT AUSF through the AIoTF and a successful authentication of the AIoT device by the AIoT AUSF.

[0237] Example 4: The method of Example 1, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; determining a response (RES) using a key associated with the AIoT device and the device ID of the AIoT device; receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and a counter value; and verifying the token to authenticate the control plane entity.

[0238] Example 5: The method of Example 4, wherein performing the mutual authentication further comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and a counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT AUSF.

[0239] Example 6: The method of any one of Examples 2-5, wherein receiving the token determined by the AIoT UDM comprises: determining, by the AIoT UDM, an Expected Response  (XRES) using the key and the device ID and the token using the key, the device ID and the counter value; comparing, by the AIoT AUSF, the XRES with the RES; and transmitting, by the AIoT AUSF, the token to the AIoT device through the AIoTF and the reader in response to the XRES matching with the RES.

[0240] Example 7: The method of any one of Examples 2-6, wherein verifying the token to authenticate the control plane entity comprises: determining an expected token using the key, the device ID, and the counter value; comparing the token with the expected token; and preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the control plane entity in response to the token matching with the expected token.

[0241] Example 8: The method of any one of Examples 1-7, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, and the AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.

[0242] Example 9: The method of any one of Examples 2-8, wherein the counter value is a sequential number or a random number.

[0243] Example 10: A method for wireless communication, the method comprising: performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity comprising an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AIoT UDM is an authentication anchor.

[0244] Example 11: The method of Example 10, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) comprising a random ID; receiving from the reader a second message (Msg2) comprising the random ID; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission a third message (Msg3) comprising the device ID, the RES, and a counter value to the reader; receiving from the reader a token, wherein the token is  determined by the AIoT UDM using the key, the device ID, and the counter value; and verifying the token to authenticate the control plane entity.

[0245] Example 12: The method of Example 11, wherein performing the mutual authentication comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT UDM.

[0246] Example 13: The method of Example 10, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission to the reader a first message (Msg1) comprising a random ID, the device ID, the RES, and a counter value; receiving from the reader a second message (Msg2) comprising the random ID; receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; and verifying the token to authenticate the control plane entity.

[0247] Example 14: The method of Example 13, wherein performing the mutual authentication comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT UDM.

[0248] Example 15: The method of any one of Examples 11-14, receiving the token determined by the AIoT UDM comprises: determining, by the AIoT UDM, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value; comparing, by the AIoT UDM, the XRES with the RES; transmitting, by the AIoT UDM, the token to the AIoT device through the AIoT AUSF, the AIoTF and the reader in response to the XRES matching with the RES.

[0249] Example 16: The method of any one of Examples 11-15, verifying the token to authenticate the control plane entity comprises: determining an expected token using the key, the device ID, and the counter value; comparing the token with the expected token; in response to the token  matching with the expected token, preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the control plane entity.

[0250] Example 17: The method of any one of Examples 10-16, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, and the AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.

[0251] Example 18: The method of any one of Examples 10-17, wherein the counter value is a sequential number or a random number.

[0252] Example 19: A method for wireless communication, the method comprising: performing mutual authentication between an Ambient Internet of Things (AIoT) device and an Application Function (AF) through a control plane entity comprising an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AF manufactured the AIoT device, and the AF is an authentication anchor.

[0253] Example 20: The method of Example 19, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) comprising a random ID; receiving from the reader a second message (Msg2) comprising the random ID; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission to the reader a third message (Msg3) comprising the device ID, the RES, and a counter value; receiving from the reader a token, wherein the token is determined by the AF using the key, the device ID, and the counter value; and verifying the token to authenticate the AF.

[0254] Example 21: The method of Example 20, wherein performing the mutual authentication comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the AF through the AIoTF and a successful authentication of the AIoT device by the AF.

[0255] Example 22: The method of Example 19, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising  a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; determining a response (RES) using a key of the AIoT device and the device ID; preparing for transmission to the reader a first message (Msg1) comprising a random ID, the device ID, the RES, and a counter value; receiving from the reader a second message (Msg2) comprising the random ID; receiving from the reader a token, wherein the token is determined by the AF using the key, the device ID, and the counter value; and verifying the token to authenticate the AF.

[0256] Example 23: The method of Example 22, wherein performing the mutual authentication comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the AF through the AIoTF and a successful authentication of the AIoT device by the AF.

[0257] Example 24: The method of Example 19, wherein performing the mutual authentication comprises: receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane; preparing for transmission to the reader a first message (Msg1) comprising a random ID and the device ID; receiving from the reader a second message (Msg2) comprising the random ID; receiving, from the AIoTF, an authentication trigger message comprising the device ID and a Random Challenge (RAND) generated by the AF; determining a response (RES) using a key of the AIoT device, the device ID and the RAND; preparing for transmission to the reader in an uplink Access Stratum (AS) service request message comprising the device ID, the RES, and a counter value; receiving from the reader a token, wherein the token is determined by the AF using the key, the device ID, and the counter value; and verifying the token to authenticate the AF.

[0258] Example 25: The method of Example 24, wherein performing the mutual authentication comprises: receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the AF through the AIoTF and a successful authentication of the AIoT device by the AIoT AF.

[0259] Example 26: The method of any one of Examples 20-25, wherein receiving the token determined by the AF comprises: determining, by the AF, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value;  comparing, by the AF, the XRES with the RES; transmitting, by the AF, the token to the AIoT device through the AIoTF and the reader in response to the XRES matching with the RES.

[0260] Example 27: The method of any one of Examples 20-26, wherein verifying the token to authenticate the AF comprises: determining an expected token using the key, the device ID, and the counter value; comparing the token with the expected token; in response to the token matching with the expected token, preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the AF.

[0261] Example 28: The method of any one of Examples 19-27, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, and the AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.

[0262] Example 29: The method of any one of Examples 19-28, wherein the counter value is a sequential number or a random number.

[0263] Example 30: An apparatus comprising: one or more processors; and a memory storing instructions that, when executed, are configured to cause the one or more processors to perform operations of any one of method Examples 1-29.

[0264] Example 31: One or more processors comprising circuitry to execute one or more instructions that, when executed, cause the one or more processors to perform operations of any one of method Examples 1-29.

[0265] Example 32: One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations of any one of method Examples 1-29.

[0266] Various components may be described as performing a task or tasks, for convenience in the description. Such descriptions should be interpreted as including the phrase “configured to. ” Reciting a component that is configured to perform one or more tasks is expressly intended not to invoke 35 USC § 112 (f) interpretation for that component.

[0267] For one or more implementations, 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.

[0268] 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 implementations to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various implementations.

[0269] Although the implementations 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.

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

Claims

1.A method for wireless communication, the method comprising:performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity comprising an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AIoT AUSF is an authentication anchor.2.The method of claim 1, wherein performing the mutual authentication comprises:receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AUSF, or AIoT UDM in the control plane;preparing for transmission to the reader a first message (Msg1) comprising a random ID and the device ID;receiving from the reader a second message (Msg2) comprising the random ID;receiving, from the AIoTF, an authentication trigger message comprising the device ID and a Random Challenge (RAND) generated by the AIoT AUSF;determining a response (RES) using a key associated with the AIoT device, the device ID of the AIoT device and the RAND;preparing for transmission to the reader in an uplink Access Stratum (AS) service request message comprising the device ID, the RES, and a counter value;receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; andverifying the token to authenticate the control plane entity.3.The method of claim 2, wherein performing the mutual authentication further comprises:receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the AIoT AUSF through the AIoTF and a successful authentication of the AIoT device by the AIoT AUSF.4.The method of claim 1, wherein performing the mutual authentication comprises:receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane;determining a response (RES) using a key associated with the AIoT device and the device ID of the AIoT device;receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and a counter value; andverifying the token to authenticate the control plane entity.5.The method of claim 4, wherein performing the mutual authentication further comprises:receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and a counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT AUSF.6.The method of any one of claims 2-5, wherein receiving the token determined by the AIoT UDM comprises:determining, by the AIoT UDM, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value;comparing, by the AIoT AUSF, the XRES with the RES; andtransmitting, by the AIoT AUSF, the token to the AIoT device through the AIoTF and the reader in response to the XRES matching with the RES.7.The method of any one of claims 2-6, wherein verifying the token to authenticate the control plane entity comprises:determining an expected token using the key, the device ID, and the counter value;comparing the token with the expected token; andpreparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the control plane entity in response to the token matching with the expected token.8.The method of any one of claims 1-7, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, andthe AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.9.The method of any one of claims 2-8, wherein the counter value is a sequential number or a random number.10.A method for wireless communication, the method comprising:performing mutual authentication between an Ambient Internet of Things (AIoT) device and a control plane entity in a network, the control plane entity comprising an AIoT Function (AIoTF) , an AIoT Authentication Server Function (AUSF) , and AIoT Unified Data Management (UDM) , wherein the AIoT UDM is an authentication anchor.11.The method of claim 10, wherein performing the mutual authentication comprises:receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane;preparing for transmission to the reader a first message (Msg1) comprising a random ID;receiving from the reader a second message (Msg2) comprising the random ID;determining a response (RES) using a key of the AIoT device and the device ID;preparing for transmission a third message (Msg3) comprising the device ID, the RES, and a counter value to the reader;receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; andverifying the token to authenticate the control plane entity.12.The method of claim 11, wherein performing the mutual authentication comprises:receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT UDM.13.The method of claim 10, wherein performing the mutual authentication comprises:receiving, from a reader associated with the AIoT device, a paging message comprising a device identifier (ID) of the AIoT device, wherein the reader interfaces with one or more of the AIoTF, AIoT AUSF, or AIoT UDM in the control plane;determining a response (RES) using a key of the AIoT device and the device ID;preparing for transmission to the reader a first message (Msg1) comprising a random ID, the device ID, the RES, and a counter value;receiving from the reader a second message (Msg2) comprising the random ID;receiving from the reader a token, wherein the token is determined by the AIoT UDM using the key, the device ID, and the counter value; andverifying the token to authenticate the control plane entity.14.The method of claim 13, wherein performing the mutual authentication comprises:receiving from the reader the token in response to the reader transmitting an authentication request comprising the device ID, the RES, and the counter value to the control plane entity and a successful authentication of the AIoT device by the AIoT UDM.15.The method of any one of claims 11-14, receiving the token determined by the AIoT UDM comprises:determining, by the AIoT UDM, an Expected Response (XRES) using the key and the device ID and the token using the key, the device ID and the counter value;comparing, by the AIoT UDM, the XRES with the RES;transmitting, by the AIoT UDM, the token to the AIoT device through the AIoT AUSF, the AIoTF and the reader in response to the XRES matching with the RES.16.The method of any one of claims 11-15, verifying the token to authenticate the control plane entity comprises:determining an expected token using the key, the device ID, and the counter value;comparing the token with the expected token;in response to the token matching with the expected token,preparing for transmission to the reader an uplink (UL) message notifying a successful authentication of the control plane entity.17.The method of any one of claims 10-16, wherein the AIoT device is configured with the device ID and the key as a first root key at a time of manufacture of the AIoT device, andthe AIoT UDM is configured with a copy of the key as a second root key, wherein the second root key is cryptographically linked to the first root key.18.An apparatus comprising:one or more processors; anda memory storing instructions that, when executed, are configured to cause the one or more processors to perform operations of any one of method claims 1-17.19.One or more processors comprising circuitry to execute one or more instructions that, when executed, cause the one or more processors to perform operations of any one of method claims 1-17.20.One or more non-transitory computer-readable media storing instructions that, when executed, cause one or more processors to perform operations of any one of method claims 1-17.

Images