Method, device and system for AIOT device temporary identifier derivation in communication networks

Abstract

This disclosure generally relates to deriving and utilizing a temporary identifier for AIoT device in wireless communication. Performed by an AIoT device, the method includes: obtaining a temporary identifier of the wireless device; and transmitting, to a network element, a first message carrying the temporary identifier.

Description

METHOD, DEVICE AND SYSTEM FOR AIOT DEVICE TEMPORARY IDENTIFIER DERIVATION IN COMMUNICATION NETWORKSTECHNICAL FIELD

[0001] This disclosure relates to wireless communication, and in particular, to deriving or obtaining an identifier for AIoT device in a wireless communication network, such as 4G, 5G, and 6G wireless communication network.BACKGROUND

[0002] Wireless communication system involving mobile communication technology (e.g., 5th Generation mobile communication technology (5G) or further 6th Generation mobile communication technology (6G) ) continually faces more and more demands, including systems deploying massive Internet of Things (IoT) devices. Identifying a legitimate IoT device is essential to permit only authorized IoT device to connect to the communication network. Developing an efficient, robust, and feasible authentication mechanism that accommodates the diverse range of low-complexity, low-cost IoT devices is crucial for facilitating the widespread deployment of IoT devices.SUMMARY

[0003] This disclosure discloses methods, systems, devices, and storage medium relates to wireless communication, and in particular, to deriving or obtaining an identifier for AIoT (Ambient IoT) device in a wireless communication network, such as 4G, 5G, and 6G wireless communication network.

[0004] In one embodiment, the present disclosure describes a method for wireless communication. Performed by a wireless device such as an AIoT device, the method includes: obtaining a temporary identifier of the wireless device; and transmitting, to a network element, a first message carrying the temporary identifier.

[0005] In another embodiment, a method for wireless communication is disclosed. Performed by a network element, the method includes: obtaining a temporary identifier of the wireless device; and receiving, from a wireless device, a first message carrying the temporary identifier. The network element may include a core network node, or network function in a core network.

[0006] In another embodiment, a network element or wireless device comprising a processor and a memory is disclosed. The processor may be configured to read computer code from the memory to implement any of the methods above.

[0007] In yet another embodiment, a computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon is disclosed. The computer code, when executed by a processor, may cause the processor to implement any one of the methods above.

[0008] The above embodiments and other aspects and alternatives of their implementations are explained in greater detail in the drawings, the descriptions, and the claims below.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] FIG. 1 shows an exemplary communication network including various terminal devices, a carrier network, data network, and service applications.

[0010] FIG. 2 shows exemplary network functions or network nodes in a communication network.

[0011] FIG. 3 shows exemplary network functions or network nodes in a wireless communication network.

[0012] FIG. 4 shows an exemplary network model for an Authentication and Key  Management for Applications (AKMA) framework.

[0013] FIG. 5 shows an example wireless network node (or network element, network entity, entity, application function) .

[0014] FIG. 6 shows an example user equipment.

[0015] FIGs. 7-8 show exemplary logic flows for configuring, synchronizing, and utilizing AIoT device temporary identifier.DETAILED DESCRIPTION

[0016] An exemplary communication network, shown as 100 in FIG. 1, may include terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. The carrier network 102, for example, may include access networks 120 and a core network 130. The carrier network 102 may be configured to transmit voice, data, and other information (collectively referred to as data traffic) among terminal devices 110 and 112, between the terminal devices 110 and 112 and the service applications 140, or between the terminal devices 110 and 112 and the other data networks 150. Communication sessions and corresponding data paths may be established and configured for such data transmission. The Access networks 120 may be configured to provide terminal devices 110 and 112 network access to the core network 130. The Access network 120 may, for example, support wireless access via radio resources, or wireline access. The core network 130 may include various network nodes or network functions configured to control the communication sessions and perform network access management and data traffic routing. The service applications 140 may be hosted by various application servers that are accessible by the terminal devices 110 and 112 through the core network 130 of the carrier network 102. A service application 140 may be deployed as a data network outside of the core network 130. Likewise, the other data networks 150 may be accessible by the terminal devices 110 and 112 through the core network 130 and may appear as either data destination or data source of a particular communication session instantiated in the  carrier network 102.

[0017] The core network 130 of FIG. 1 may include various network nodes or functions geographically distributed and interconnected to provide network coverage of a service region of the carrier network 102. These network nodes or functions may be implemented as dedicated hardware network elements. Alternatively, these network nodes or functions may be virtualized and implemented as virtual machines or as software entities. A network node may each be configured with one or more types of network functions. These network nodes or network functions may collectively provide the provisioning and routing functionalities of the core network 130. The term “network nodes” and “network functions” are used interchangeably in this disclosure.

[0018] FIG. 2 further shows an exemplary division of network functions in the core network 130 of a communication network 200. While only single instances of network nodes or functions are illustrated in FIG. 2, those having ordinary skill in the art readily understand that each of these network nodes may be instantiated as multiple instances of network nodes that are distributed throughout the core network 130. As shown in FIG. 2, the core network 130 may include but is not limited to network nodes such as access management network node (AMNN) 230, authentication network node (AUNN) 260, network data management network node (NDMNN) 270, session management network node (SMNN) 240, data routing network node (DRNN) 250, policy control network node (PCNN) 220, and application data management network node (ADMNN) 210. Exemplary signaling and data exchange between the various types of network nodes through various communication interfaces are indicated by the various solid connection lines in FIG. 2. Such signaling and data exchange may be carried by signaling or data messages following predetermined formats or protocols.

[0019] The implementations described above in FIGs. 1 and 2 may be applied to both wireless and wireline communication systems. FIG. 3 illustrates an exemplary cellular wireless communication network 300 based on the general implementation of the communication network 200 of FIG. 2. FIG. 3 shows that the wireless communication  network 300 may include user equipment (UE) 310 (functioning as the terminal device 110 of FIG. 2) , radio access network (RAN) 320 (functioning as the access network 120 of FIG. 2) , data network (DN) 150, and core network 130 including access management function (AMF) 330 (functioning as the AMNN 230 of FIG. 2) , session management function (SMF) 340 (functioning as the SMNN 240 of FIG. 2) , application function (AF) 390 (functioning as the ADMNN 210 of FIG. 2) , user plane function (UPF) 350 (functioning as the DRNN 250 of FIG. 2) , policy control function 322 (functioning as the PCNN 220 of FIG. 2) , authentication server function (AUSF) 360 (functioning as the AUNN 260 of FIG. 2) , and universal data management (UDM) function 370 (functioning as the UDMNN 270 of FIG. 2) . Again, while only single instances for some network functions or nodes of the wireless communication network 300 (the core network 130 in particular) are illustrated in FIG. 3, those of ordinary skill in the art readily understand that each of these network nodes or functions may have multiple instances that are distributed throughout the wireless communication network 300. While the AF 390 is depicted as part of the core network 130 in FIG. 3, they may be considered as associated with particular service applications 140 and may be considered as being outside of the core network 140. In this disclosure, various functions deployed in the wireless network as described above may also be referred to as function entities, which may be implemented as a network node, a network element, a logical function, via hardware, software, or a combination thereof.

[0020] In FIG. 3, the UE 310 may be implemented as various types of mobile devices that are configured to access the core network 130 via the RAN 320. The UE 310 may include but is not limited to mobile phones, laptop computers, tablets, Internet-Of-Things (IoT) devices, distributed sensor network nodes, wearable devices, and the like. The UE may also be Multi-access Edge Computing (MEC) capable UE that supports edge computing. The RAN 320 for example, may include a plurality of radio base stations distributed throughout the service areas of the carrier network. The communication between the UE 310 and the RAN 320 may be carried in over-the-air (OTA) radio interfaces as indicated by 311 in FIG. 3.

[0021] Continuing with FIG. 3, the UDM 370 may form a permanent storage or database for user contract and subscription data. The UDM may further include an authentication credential repository and processing function (ARPF, as indicated in 370 of FIG. 3) for storage of long-term security credentials for user authentication, and for using such long-term security credentials as input to perform computation of encryption keys as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, the UDM / ARPF 370 may be located in a secure network environment of a network operator or a third-party.

[0022] The AMF / SEAF 330 may communicate with the RAN 320, the SMF 340, the AUSF 360, the UDM / ARPF 370, and the Policy Control Function (PCF) 322 via communication interfaces indicated by the various solid lines connecting these network nodes or functions. The AMF / SEAF 330 may be responsible for UE to non-access stratum (NAS) signaling management, and for provisioning registration and access of the UE 310 to the core network 130 as well as allocation of SMF 340 to support communication need of a particular UE. The AMF / SEAF 330 may be further responsible for UE mobility management. The AMF may also include a security anchor function (SEAF, as indicated in 330 of FIG. 3) that, as described in more detail below, and interacts with AUSF 360 and UE 310 for user authentication and management of various levels of encryption / decryption keys. The AUSF 360 may terminate user registration / authentication / key generation requests from the AMF / SEAF 330 and interact with the UDM / ARPF 370 for completing such user registration / authentication / key generation.

[0023] The SMF 340 may be allocated by the AMF / SEAF 330 for a particular communication session instantiated in the wireless communication network 300. The SMF 340 may be responsible for allocating UPF 350 to support the communication session and data flows therein in a user data plane and for provisioning / regulating the allocated UPF 350 (e.g., for formulating packet detection and forwarding rules for the allocated UPF 350) . Alternative to being allocated by the SMF 340, the UPF 350 may be allocated by the AMF / SEAF 330 for the particular communication session and data flows. The UPF 350 allocated and provisioned by the SMF 340 and AMF / SEAF 330 may be responsible for data  routing and forwarding and for reporting network usage by the particular communication session. For example, the UPF 350 may be responsible for routing end-end data flows between UE 310 and the DN 150, between UE 310 and the service applications 140. The DN 150 and the service applications 140 may include but are not limited to data network and services provided by the operator of the wireless communication network 300 or by third-party data network and service providers.

[0024] The PCF 322 may be responsible for managing and providing various levels of policies and rules applicable to a communication session associated with the UE 310 to the AMF / SEAF 330 and SMF 340. As such, the AMF / SEAF 330, for example, may assign SMF 340 for the communication session according to policies and rules associated with the UE 310 and obtained from the PCF 322. Likewise, the SMF 340 may allocate UPF 350 to handle data routing and forwarding of the communication session according to policies and rules obtained from the PCF 322.

[0025] While FIGs. 1-3 and the various exemplary implementations described below are based on cellular wireless communication networks, the scope of this disclosure is not so limited and the underlying principles are applicable to other types of wireless and wireline communication networks.

[0026] Network identity and data security in the wireless communication network 300 of FIG. 3 may be managed via user authentication processes provided by the AMF / SEAF 330, the AUSF 360, and the UDM / ARPF 370. In particularly, the UE 310 may first communicate with AMF / SEAF 330 for network registration and may then be authenticated by the AUSF 360 according to user contract and subscription data in the UDM / ARPF 370. Communication sessions established for the UE 310 after user authentication to the wireless communication network 300 may then be protected by the various levels of encryption / decryption keys. The generation and management of the various keys may be orchestrated by the AUSF 360 and other network functions in the communication network 300.

[0027] AKMA Framework

[0028] In the wireless communication network, the Application Function (AF, or application function entity) may provide application service to a UE. The AF may be deployed in various locations, such as a Home Public Land Mobile Network (HPLMN) of the UE, a Visited Public Land Mobile Network (VPLMN) of the UE (e.g., when the UE roams to the VPLMN) , or a Data Network (DN) which is external to the HPLMN and the VPLMN. Secure or encrypted data communication between the AF and the UE may be implemented under an Authentication and Key Management for Applications (AKMA) framework. The AKMA framework may be based on various authentication procedures such as the 5G Authentication and Key Agreement (5G-AKA) method, the Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') method, the Extensible Authentication Protocol –Transport Layer Security (EAP-TLS) method, or the like.

[0029] FIG. 4 illustrates an exemplary network model 400 for implementing an AKMA framework. This model includes various network elements. Each network element may be implemented as a physical entity, or a logical entity providing a particular set of network functions. A logical entity may be based on software, hardware, firmware, of any combination thereof. For example, a logical entity may include a server providing the function. For another example, a logical entity may be implemented based on cloud-based service or platform, such as Software as a service (SaaS) , Platform as a service (PaaS) , etc.

[0030] The AKMA Anchor Function (AAnF) 412 provides a security anchor function in the HPLMN. The AAnF stores the AKMA Anchor Key (KAKMA) for AKMA service associated with UE 424, which is received from the Authentication Server Function (AUSF) 416 after the UE 424 completes a successful primary authentication. The AAnF may also generate the key material to be used between the UE and the Application Function (AF) 420 and maintains UE AKMA context (also referred to as AKMA security context) .

[0031] The Access and Mobility Management Function (AMF) 418 provides following  functions: registration management, connection management, security and access management, reachability management, mobility management. For each UE under its management, the AMF 418 and the respective UE maintain an AMF key (KAMF) .

[0032] The AF 420 may provide application service to the UE. Under the AKMA framework, the AF may request for its AKMA Application Key, denoted as KAF, from the AAnF using an identifier for the KAKMA. The identifier may include an AKMA Key Identifier (A-KID) . The AAnF may only provide the KAF to the AF after the AF is authenticated and authorized by the operator network. The AF may be located inside or outside the operator's network. In this disclosure, for simplicity, the AKMA Application Key (denoted as KAF, or KAF) may also be referred to as the AF key.

[0033] In some example implementations, the A-KID may include: A-TID (AKMA Temporary UE Identifier) , and HN-ID (identity of home network) . A-KID identifies the KAKMA key of the UE. A-KID may be in a Network Access Identifier (NAI) format, i.e., username@realm. Specifically, the username part may include the Routing Identifier (RID) of the UE and the AKMA Temporary UE Identifier (A-TID) , and the realm part may include Home Network Identifier.

[0034] A-TID may be derived from KAUSF and SUPI (Subscription Permanent Identifier) of the UE. For example, A-TID = KDF ( "A-TID" , SUPI, KAUSF) , where KDF is the key derivation function.

[0035] The Network Exposure Function (NEF) 410 may be configured to enable and authorize external AFs to access the AKMA service and forward the AKMA service request towards the AAnF. The NEF may also perform the AAnF selection in case there are multiple AAnFs.

[0036] The AUSF 416 may provide the Subscription Permanent Identifier (SUPI) and AKMA key material (e.g., A-KID, KAKMA) of the UE to the AAnF. The AUSF may also perform the AAnF selection.

[0037] The UDM may store AKMA subscription data of the subscriber (or the UE subscribed to the wireless communication network) .

[0038] Referring to FIG. 4, various interfaces may be involved in the AKMA framework. These interfaces may include Nnef, Naanf, Nudm, Uausf, and Namf and may be referred to as Service Based Interface (SBI) , as each interface corresponds to a service provided by a network element. For example, Nnef represnets the SBI utilized by the NEF; Naanf represents the SBI utilized by the AAnF; and Nudm represents the SBI utilized by the UDM. The network elements may interact with each other via the various SBIs. The SBI may provide security protection. For example, the SBI may be confidentiality, integrity and replay protected.

[0039] FIG. 4 shows the implementation where the AAnF is deployed as a standalone function. Other deployment options may be chosen. For example, the AAnF may be co-located with the AUSF, or the AAnF may be co-located with the NEF.

[0040] FIG. 5 shows an example of electronic device 500 to implement various network functions (NFs) , network nodes, network elements, network entities, such as a network base station (e.g., a radio access network node) , a core network (CN) , a core network element / entity / node (e.g., an AMF, a UDM, an AAnF, etc. ) , an operation and maintenance (OAM) , and the like. Optionally in one implementation, the example electronic device 500 may include radio transmitting / receiving (Tx / Rx) circuitry 508 to transmit / receive communication with UEs and / or other base stations. Optionally in one implementation, the electronic device 500 may also include network interface circuitry 509 to communicate the base station with other base stations and / or a core network, e.g., optical or wireline interconnects, Ethernet, and / or other data transmission mediums / protocols. The electronic device 500 may optionally include an input / output (I / O) interface 506 to communicate with an operator or the like.

[0041] The electronic device 500 may also include system circuitry 504. System circuitry 504 may include processor (s) 521 and / or memory 522. Memory 522 may include an  operating system 524, instructions 526, and parameters 528. Instructions 526 may be configured for the one or more of the processors 521 to perform the functions of the network node. The parameters 528 may include parameters to support execution of the instructions 526. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping assignments, and / or other parameters.

[0042] In this disclosure, a network function / network entity / entity, such as a Network Function (NF) , an AMF, an AUSF, a UDM, an AAnF, an NEF, an AF, may be implemented in hardware, software, a combination of hardware and software, and may be implemented or integrated in the electronic device 500. They may also be implemented as a logical entity hosted by the electronic device 500.

[0043] FIG. 6 shows an example of an electronic device to implement a terminal device 600 (for example, an AIoT device, a UE, etc. ) . The device 600 may be a mobile device, for example, a smart phone or a mobile communication module disposed in a vehicle. The device 600 may include a portion or all of the following: communication interfaces 602, a system circuitry 604, an input / output interfaces (I / O) 606, a display circuitry 608, and a storage 609. The display circuitry may include a user interface 610. The system circuitry 604 may include any combination of hardware, software, firmware, or other logic / circuitry. The system circuitry 604 may be implemented, for example, with one or more systems on a chip (SoC) , application specific integrated circuits (ASIC) , discrete analog and digital circuits, and other circuitry. The system circuitry 604 may be a part of the implementation of any desired functionality in the device 600. In that regard, the system circuitry 604 may include logic that facilitates, as examples, decoding and playing music and video, e.g., MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; running applications; accepting user inputs; saving and retrieving application data; establishing, maintaining, and terminating cellular phone calls or data connections for, as one example, internet connectivity; establishing, maintaining, and terminating wireless network connections, Bluetooth connections, or other connections; and displaying relevant information on the user interface 610. The user interface 610 and the inputs / output (I / O) interfaces 606 may include a graphical user interface, touch  sensitive display, haptic feedback or other haptic output, voice or facial recognition inputs, buttons, switches, speakers and other user interface elements. Additional examples of the I / O interfaces 606 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headset and microphone input  / output jacks, Universal Serial Bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors) , and other types of inputs.

[0044] Referring to FIG. 6, the communication interfaces 602 may include a Radio Frequency (RF) transmit (Tx) and receive (Rx) circuitry 616 which handles transmission and reception of signals through one or more antennas 614. The communication interface 602 may include one or more transceivers. The transceivers may be wireless transceivers that include modulation  / demodulation circuitry, digital to analog converters (DACs) , shaping tables, analog to digital converters (ADCs) , filters, waveform shapers, filters, pre-amplifiers, power amplifiers and / or other logic for transmitting and receiving through one or more antennas, or (for some devices) through a physical (e.g., wireline) medium. The transmitted and received signals may adhere to any of a diverse array of formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM) , frequency channels, bit rates, and encodings. As one specific example, the communication interfaces 602 may include transceivers that support transmission and reception under the 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS) , High Speed Packet Access (HSPA) +, 4G  / Long Term Evolution (LTE) , 5G, and 6G standards. The techniques described below, however, are applicable to other wireless communications technologies whether arising from the 3rd Generation Partnership Project (3GPP) , GSM Association, 3GPP2, IEEE, or other partnerships or standards bodies.

[0045] Referring to FIG. 6, the system circuitry 604 may include one or more processors 621 and memories 622. The memory 622 stores, for example, an operating system 624, instructions 626, and parameters 628. The processor 621 is configured to execute the instructions 626 to carry out desired functionality for the device 600. The parameters 628 may provide and specify configuration and operating options for the instructions 626. The  memory 622 may also store any BT, WiFi, 3G, 4G, 5G, 6G or other data that the device 600 will send, or has received, through the communication interfaces 602. In various implementations, a system power for the device 600 may be supplied by a power storage device, such as a battery or a transformer.

[0046] Note that in this disclosure, the AIoT device may only implement partial of the hardware and / or software components of device 600, to achieve an ultra-low complexity design goal.

[0047] AIoT Device and Its Temporary identifier

[0048] Ambient IoT (AIoT) device is a special type of IoT device that is designed with an ultra-low complexity architecture, in terms of hardware and / or software. This simplified design approach is driven by the need to address power, cost, and resource constraints inherent in these types of devices. By employing an ultra-low complexity design approach, AIoT devices can be deployed in a cost-effective and energy-efficient manner, enabling widespread adoption and integration into various environments and applications, such as smart homes, industrial monitoring, inventory monitoring, environmental sensing, healthcare monitoring, and the like.

[0049] Ambient IoT device is much cheaper compared to previous generations of IoT devices, like the NB-IoT (Narrow Band IoT) , CIoT (Consumer IoT) , RedCap (Reduced Capacity) IoT devices. Exemplarily, The AIoT device may have the capability to collect energy from radio waves through a process known as AIoT energy harvesting, which involves utilizing the power present in ambient radio waves to sustain the device.

[0050] The AIoT technology, while considered a key enabler for cost-efficient solutions that will revolutionize the way information is tracked, monitored, and managed, presents unique challenges that must be addressed. One of the primary challenges has to do with the ultra-low complexity design of AIoT devices, characterized by very limited hardware / software capabilities, and stringent power and resource (e.g., memory) constraints.  This design approach, while essential for cost-effectiveness and long-term operability, imposes restrictions on the computational power, memory resources, and energy available to the AIoT devices. Therefore, existing, traditional security model, such as the subscription model may not be suitable for AIoT devices. New mechanisms may need to be adapted to accommodate the resource-constrained nature of AIoT devices, to achieve a balance between robust security, efficient information exchange (e.g., with core network) , and energy optimization.

[0051] In this disclosure, various embodiments are described, in order to protect sensitive AIoT device identity information, for example, when the AIoT device is under operator control.

[0052] In this disclosure, the permanent subscriber identifier is not allowed to be sent in clear text over Uu interface (i.e., the air interface) . Exemplarily, only a temporary identifier of the AIoT device is sent over Uu interface in clear text, for example, when the UE is paged, and the temporary identifier is only allowed to be used for a predefined number of times (e.g., temporary identifier is allowed to be used for one time only) .

[0053] Specifically, the embodiments in this disclosure are based on at least one of the following assumptions:

[0054] · The AIoT device has higher complexity than a radio frequency identification (RFID) tag that only reflects a preconfigured device ID, but significantly lower complexity than other types of 3GPP IoT devices, such as NB-IoT, CIoT, and RedCap IoT devices.

[0055] · The AIoT device has a non-volatile storage capability.

[0056] · The AIoT device may support a light weight temporary ID (Temp ID) generation algorithm, which is used to generate a TempID that is enough to avoid unauthorized AIoT device tracking.

[0057] In this disclosure, the permanent identifier of the AIoT device (e.g., device ID) , as  a sensitive piece of information, is protected to maintain privacy and prevent security breaches, and is not allowed to be sent via the Uu interface. Instead, an alternative AIoT device identifier is introduced. In some example implementations, this newly introduced alternative AIoT device identifier may be distinct from various any other existing UE identifiers in wireless standards, such as Subscription Concealed Identifier (SUCI) , Subscription Permanent Identifier (SUPI) , or 5G-GUTI (5G Globally Unique Temporary Identifier) . This alternative AIoT device identifier may also be referred to as a temporary identifier (TempID) of the AIoT device.

[0058] The TempID may have following characteristics:

[0059] First, the TempID is synchronized between the AIoT device and the core network (CN) . In case the TempID is out of sync between the CN Network Function (NF) and the AIoT device, the CN NF and the AIoT may need to re-synchronize the TempID.

[0060] Second, as the name suggests, the TempID undergoes frequent refreshing. For example, it may be renewed / refreshed after a predefined number of uses (e.g., after being transmitted over the air interface for n times) , where n is an integer. In some example implementations, n equals to 1, which means that the TempID is refreshed each time it is sent over the air interface. The TempID refresh is synchronized between the core network and the AIoT device.

[0061] For another example, the TempID may have a predefined lifecycle and should be renewed / refreshed once it reaches its lifecycle.

[0062] Third, the TempID is encrypted by using a TempID derivation function, with an encryption key and an input string. The encryption may include a key under the AKMA framework or other type of security frameworks, such an AMF key (KAMF) , an AUSF key (KAUSF) , or another long-term preconfigured key. The input string to the derivation function may be based at least in part on a fixed device ID of the AIoT device, and some other parameters, such as a counter, or a random number. More details on the TempID derivation  will be described later in this disclosure.

[0063] In this disclosure, the core network (CN) may refer to a CN Network Function (NF) , a CN node, etc. The core network NF may include, for example, a stand-alone network function, a network function that is co-located with other functions within the core network, such as AMF, AUSF, UDM, or an Authentication Function.

[0064] In some example implementations, an initial TempID may be provisioned on both the CN NF and the AIoT device. Specifically, the initial TempID of the AIoT device may be provisioned via an onboarding procedure to onboard the AIoT device to the core network, or a registration procedure to register the AIoT device to the core network. The provision may be performed by the CN NF. Additionally or alternatively, the AIoT device may be provisioned with some other initial credential parameters, which can be used to derive the TempID (including the initial TempID and subsequent refreshed TempID) .

[0065] In some example implementations, during the onboarding procedure (to onboard the AIoT device) , the CN NF may retrieve information from another NF or AF (Application Function) to onboard the AIoT device. For example, the CN NF may establish an IP connection to an AF based on URL (Uniform Resource Locator) and / or FQDN (Fully Qualified Domain Name) associated with the AF, which holds additional onboarding information for the AIoT device.

[0066] Embodiment 1

[0067] In this embodiment, the AIoT device may have the hardware and / or software capability to execute an identifier derivation function in order to obtain an AIoT TempID. This capability allows the AIoT device to independently generate or obtain its TempID.

[0068] To maintain synchronization with respect to the TempID, both the AIoT device and the core network involve in a synchronous AIoT TempID update procedure. The exemplary steps for generating and utilizing the AIoT TempID are described in details below with reference to FIG. 7. An exemplary method may include a portion or all of the  following steps.

[0069] Precondition (step 0) :

[0070] As a precondition, the AIoT device is synchronized with the core network (CN) (e.g., a CN node, a CN NF) with respect to initial credential information.

[0071] The initial credential information may include an initial temporary identifier (TempID) . Additionally or alternatively, the initial credential information may include at least one of:

[0072] ·an encryption key which is used for generating a TempID;

[0073] · a random number; or

[0074] · an initial counter.

[0075] Exemplarily, the value of the initial counter may be set to 0, or another predefined number.

[0076] The initial credential information may be provisioned to the AIoT device and / or the CN side (e.g., CN node, CN NF) through at least one of:

[0077] · an onboarding procedure or a registration procedure, to onboard or register the AIoT device with the core network; or

[0078] · a Non Access Stratus (NAS) procedure or an Access Stratum (AS) procedure.

[0079] Step 1:

[0080] If there is no initial TempID being provisioned in step 0, an initial TempID may be generated in parallel by the AIoT device and the core network according to a TempID derivation function using the encryption key, and various input parameters. The derivation function will be described with more details later.

[0081] Step 2:

[0082] When the AIoT device has information that needs to be transmitted to the core network, such as a service message triggered by a specific condition or event, the AIoT device may send an AIoT message to a reader. The AIoT message may include the information (AIoT information to be more specific) to be reported and the TempID of the AIoT device.

[0083] As an example, the AIoT device may be a sensor type device that monitors its surrounding area / environment. This AIoT device is designed to detect and measure various environmental parameters such as temperature or moisture levels. If the AIoT device detects that a specific condition is met or exceeded, for instance, if the temperature surpasses a predefined threshold or the moisture level rises above a certain limit, the device is programmed to trigger a service message. This service message serves as an alert or notification, indicating that the monitored environmental condition has satisfied the predetermined criteria, prompting appropriate action or response as deemed necessary by the core network.

[0084] In some example implementations, the reader may be considered as a relay or a proxy between the AIoT device and the core network. The reader may include, for example, a UE, or a base station. Specifically, the UE or the base station may be positioned in close proximity to the AIoT device, enabling the AIoT device to transmit and / or receive signals with low power requirements.

[0085] Step 3:

[0086] The reader may transfer the AIoT message to the core network.

[0087] Step 4:

[0088] The core network may use the TempID carried in the AIoT message to identify the particular AIoT device and perform corresponding operations as indicated by the AIoT  message. The core network may verify the validity of the AIoT device based on the TempID. For example, the core network may verify the received TempID (or information decrypted from it) against a database of registered and authorized AIoT devices, to ensure that the TempID corresponds to a legitimate AIoT device.

[0089] Optionally, as an extra layer for security, the core network may further reinforce the verification process by verifying additional subscription data of the AIoT device.

[0090] Step 5:

[0091] The core network may respond to the AIoT message with an acknowledgement to the reader.

[0092] If random number is chosen to be used to generate TempID, the core network may generate a new / refreshed random number and include it in the response. The refreshed random number will be used for generating a refreshed TempID for subsequent use.

[0093] Step 6:

[0094] The reader may transfer the acknowledgement to the AIoT device.

[0095] Step 7:

[0096] In this step, the AIoT device and the core network perform a re-synchronization process to update the TempID of the AIoT device. This involves generating a new, refreshed, or updated TempID for subsequent communication, by using the TempID derivation function. Specifically, both the AIoT device and the core network may independently execute the TempID derivation function.

[0097] If random number is used to generate TempID, the new random number in step 5 will be used in both sides. If counter is used to generate TempID, both the AIoT device and the core network will increment the current counter by n to obtain a refreshed counter. This refreshed counter will then be employed by both the AIoT device and the core network to  derive a new TempID derivation in both sides, n is an integer. In some example implementations, n equals to 1.

[0098] An exemplary TempID derivation function is described herein. The TempID derivation function may utilize the encryption key (i.e., the TempID generation key) as the input key. The encryption key may include keys under the AKMA framework, such as the AMF key (KAMF) , the AUSF key (KAUSF) , etc., or another type of long term key which is preconfigured in both the AIoT device the core network side (e.g., CN NF) . Exemplarily, the encryption key may be 256 bits. The equation below may be used to form the input string S to the TempID derivation function: S = FC || P0 || L0 || P1 || L1 || P2 || L2 || ... || Pn || Ln

[0099] where:

[0100] “||” is the concatenation operator, n is an integer.

[0101] FC is used to distinguish between different instances of the algorithm. FC may be a single octet, or consists of two octets in the form of FC1|| FC2.

[0102] P0 ... Pn are the n+1 input parameters, and

[0103] L0 ... Ln are the two-octet representations of the length of the corresponding input parameter encodings P0 ... Pn.

[0104] As an example, the input parameters may be set to:

[0105] FC = a predefined number;

[0106] P0 = "TempID" . That is, the current TempID may be used as part of the input to derive a refreshed TempID.

[0107] L0 = length of "TempID" ; (e.g., 0x00 0x06) ;

[0108] P1 = device ID. The device ID is a fixed, unique identifier assigned to the AIoT. The device ID may be a universally unique ID.

[0109] L1 = length of device ID;

[0110] P2 = random number or counter;

[0111] L2 = length of random number or counter.

[0112] In some example implementations, to further reduce the burden (e.g., the computation complexity to derive the new TempID) , instead of using AIoT device to derive the new TempID, this task may be delegated to the reader. That is, the reader may generate the refreshed TempID based on the newly generated random number (from core network) , or the incremented counter. For example, in the case of a random number-based approach, the core network generates a refreshed random number and securely transmits it to the reader. The reader then utilizes this random number to derive the refreshed TempID using the TempID derivation function, and then transmits the derived TempID to the AIoT device. Similarly, in the case of counter-based approach, the reader increments the counter synchronously with the core network, generates the refreshed TempID based on the incremented counter, and then transmits the result to the AIoT device.

[0113] In some example implementations, the reader may act as a central hub for generating the TempID. Specifically, the reader, based on the refreshed random number (from the core network) , or the incremented counter, may derive a refreshed TempID. The reader may then transmit the refreshed TempID to both the AIoT device and the core network.

[0114] Note that various timings to increment the counter on each side (AIoT and core network) may be supported. For example, AIoT device may increment the counter at one of following points: 1) once after the AIoT message is transmitted; or 2) an acknowledgement from the core network is received.

[0115] In this embodiment, as an example, once a TempID of the AIoT device is exposed to the air interface (e.g., in step 2) , it will trigger a refresh of the TempID. That is, the existing TempID will be discarded, and a new TempID will be generated. From the CN  side, once an AIoT message is received carrying the TempID (e.g., in step 3) , it will trigger the CN side to refresh the TempID for the AIoT device.

[0116] Embodiment 2:

[0117] In this embodiment, the core network assumes the primary responsibility for driving the process of TempID derivation and distribution, thereby alleviating the AIoT device from the computational burden of calculating the refreshed TempID. This centralized approach offloads the TempID derivation task from the potentially resource-constrained AIoT device. The exemplary steps for generating and utilizing the AIoT TempID are described in details below with reference to FIG. 8. An exemplary method may include a portion or all of the following steps.

[0118] Precondition (step 0) :

[0119] As a precondition, the AIoT device is synchronized with the core network (CN) (e.g., a CN node, a CN NF) with respect to initial credential information, which includes an initial temporary identifier (TempID) .

[0120] The initial credential information may be provisioned to the AIoT device and / or the CN side (e.g., CN node, CN NF) through at least one of:

[0121] · an onboarding procedure or a registration procedure, to onboard or register the AIoT device with the core network; or

[0122] · a Non Access Stratus (NAS) procedure or an Access Stratum (AS) procedure.

[0123] Step 1:

[0124] When the AIoT device has information that needs to be transmitted to the core network, such as a service message triggered by a specific condition or event, the AIoT device may send an AIoT message to a reader. The AIoT message may include the information to be reported and the TempID of the AIoT device.

[0125] In some example implementations, the reader may be considered as a relay or a proxy between the AIoT device and the core network. The reader may include, for example, a UE, or a base station. Specifically, the UE or the base station may be positioned in close proximity to the AIoT device, enabling the AIoT device to transmit and / or receive signals with low power requirements.

[0126] Step 2:

[0127] The reader may transfer the AIoT message to the core network.

[0128] Step 3:

[0129] The core network may use the TempID carried in the AIoT message to identify the particular AIoT device and perform corresponding operations as indicated by the AIoT message. The core network may verify the validity of the AIoT device based on the TempID. For example, the core network may verify the received TempID against a database of registered and authorized AIoT devices, to ensure that the TempID corresponds to a legitimate AIoT device.

[0130] Optionally, as an extra layer for security, the core network may further reinforce the verification process by verifying additional subscription data of the AIoT device.

[0131] The core network may generate a new, refreshed, or updated TempID for subsequent communication, according to the TempID derivation function.

[0132] If random number is used to generate TempID, the core network may generate a new / refreshed random number. If counter is used to generate TempID, the core network will increment the current counter by n to obtain a refreshed counter. This refreshed counter will then be employed by the core network to derive a new TempID, n is an integer. In some example implementations, n equals to 1.

[0133] The details for generating a refreshed TempID by using a TempID derivation function may be found in previous embodiment and is omitted herein for the sake of  simplicity.

[0134] Step 4:

[0135] The core network may respond to the AIoT message with an acknowledgement to the reader. The response message may carry the refreshed TempID that is generated by the core network.

[0136] Step 5:

[0137] The reader may transfer the response message to the AIoT device, carrying the refreshed TempID. The AIoT device may update its TempID based on the response message.

[0138] In this embodiment, as an example, once a TempID of the AIoT device is exposed to the air interface (e.g., in steps 1-2) , it will trigger the CN to refresh of the TempID. That is, the existing TempID will be discarded, and a new TempID will be generated. The newly generated TempID will be distributed to the AIoT.

[0139] In some further embodiments, the core network may determine a manner on how to synchronize AIoT TempID based on, for example, AIoT device capability information. In some example implementations, the core network (e.g., a CN NF) may determine whether an AIoT device supports TempID derivation by, for example, querying a database using TempID (or information decrypted from TempID) as an index. If the AIoT device is capable of deriving a TempID, and / or if the AIoT device agrees to derive its own TempID, then the core network does not need to forward the refreshed TempID to the AIoT device. Note that the core network may still need to transmit the refreshed random number, if a random number is employed to derive the TempID. If the AIoT device is not capable of deriving a TempID, and / or if the AIoT device denies to derive its own TempID, then the core network may decide to transfer a refreshed TempID to the AIoT device.

[0140] In some further embodiments, as an extra layer of security, the credential  information such as TempID and / or random number communicated between the AIoT device and the core network may be encrypted by, for example, the encryption key (e.g., as provisioned in step 0 or previous embodiments) .

[0141] Performed by a wireless device, an exemplary method according to embodiments in this disclosure may include obtaining a temporary identifier of the wireless device; and transmitting, to a network element, a first message carrying the temporary identifier.

[0142] In any portion or combination of the implementations above, the wireless device comprises an AIoT device.

[0143] In any portion or combination of the implementations above, the first message further carries information collected or sensed by the wireless device from its surrounding environment.

[0144] In any portion or combination of the implementations above, communication between the wireless device and the network element is via a reader device, the reader device comprising at least one of: a UE, or a base station.

[0145] In any portion or combination of the implementations above, the network element comprises a network function in a core network.

[0146] In any portion or combination of the implementations above, the wireless device is provisioned with at least one of following credential information that is synchronized with the network element: an initial temporary identifier; an encryption key; a counter; or a random number.

[0147] In any portion or combination of the implementations above, the encryption key comprises at least one of: an AMF key, Kamf, that is specific to the wireless device; or an AKMA Authentication Server Function (AUSF) key, Kausf, that is specific to the wireless device.

[0148] In this disclosure, message types and / or message names (e.g., as shown in FIGs. 7-8) are for exemplary purpose only. Different message types and / or message names may  be chosen in implementation, and should still be covered by this disclosure, as far as the underlying principle is the same, for example, if the messages are used for a same purpose.

[0149] In this disclosure, a single information element in a message may be split into multiple information elements. Multiple information element may also be combined into a single information element.

[0150] In this disclosure, the steps in each embodiment are for illustration purposes only and other alternatives may be derived based on the disclosed embodiments as desired. Some steps described in an embodiment may be optional, while some steps provide alternative, parallel solution to other steps. For example, only part of the steps may need to be performed. For another example, the sequence of the steps may be adjusted. For another example, several steps may be combined (e.g., several messages may be combined in one message) . For yet another example, a single step may be split (e.g., one message may be sent via two sub-messages) .

[0151] The accompanying drawings and description above provide specific example embodiments and implementations. The described subject matter may, however, be embodied in a variety of different forms and, therefore, covered or claimed subject matter is intended to be construed as not being limited to any example embodiments set forth herein. A reasonably broad scope for claimed or covered subject matter is intended. Among other things, for example, subject matter may be embodied as methods, devices, components, systems, or non-transitory computer-readable media for storing computer codes. Accordingly, embodiments may, for example, take the form of hardware, software, firmware, storage media or any combination thereof. For example, the method embodiments described above may be implemented by components, devices, or systems including memory and processors by executing computer codes stored in the memory.

[0152] Throughout the specification and claims, terms may have nuanced meanings suggested or implied in context beyond an explicitly stated meaning. Likewise, the phrase “in one embodiment / implementation” as used herein does not necessarily refer to the same  embodiment and the phrase “in another embodiment / implementation” as used herein does not necessarily refer to a different embodiment. It is intended, for example, that claimed subject matter includes combinations of example embodiments in whole or in part.

[0153] In general, terminology may be understood at least in part from usage in context. For example, terms, such as “and” , “or” , or “and / or, ” as used herein may include a variety of meanings that may depend at least in part on the context in which such terms are used. Typically, “or” if used to associate a list, such as A, B or C, is intended to mean A, B, and C, here used in the inclusive sense, as well as A, B or C, here used in the exclusive sense. In addition, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a, ” “an, ” or “the, ” may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0154] Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present solution should be or are included in any single implementation thereof. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present solution. Thus, discussions of the features and advantages, and similar language, throughout the specification may, but do not necessarily, refer to the same embodiment.

[0155] Furthermore, the described features, advantages and characteristics of the present solution may be combined in any suitable manner in one or more embodiments. One of ordinary skill in the relevant art will recognize, in light of the description herein, that the present solution can be practiced without one or more of the specific features or advantages  of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present solution.

Claims

1.A method for wireless communication, performed by a wireless device, comprising:obtaining a temporary identifier of the wireless device; andtransmitting, to a network element, a first message carrying the temporary identifier.2.The method of claim 1, wherein the wireless device comprises an Ambient Internet of Things (AIoT) device.3.The method of claim 1, wherein the first message further carries information collected or sensed by the wireless device from its surrounding environment.4.The method of claim 1, wherein communication between the wireless device and the network element is via a reader device, the reader device comprising at least one of: a User Equipment (UE) , or a base station.5.The method of claim 1, wherein the network element comprises a network function in a core network.6.The method of any one of claims 1-5, wherein the wireless device is provisioned with at least one of following credential information that is synchronized with the network element:an initial temporary identifier;an encryption key;a counter; ora random number.7.The method of claim 6, wherein the credential information is provisioned via at least one of:an onboarding procedure for the wireless device;a registration procedure for the wireless device;a Non Access Stratum (NAS) procedure; oran Access Stratum (AS) procedure.8.The method of any one of claims 6-7, wherein the encryption key comprises at least one of:an AMF (Access Management Function) key, Kamf, that is specific to the wireless device; oran AKMA (Authentication and Key Management for Applications) Authentication Server Function (AUSF) key, Kausf, that is specific to the wireless device.9.The method of any one of claims 6-7, wherein obtaining the temporary identifier comprises generating the temporary identifier using a key derivation function based on at least one of:the encryption key;the counter; orthe random number.10.The method of any one of claims 6-7, further comprising:receiving, from the network element, a second message as a response to the first message; andupdating the temporary identifier to obtain an updated temporary identifier.11.The method of claim 10, wherein updating the temporary identifier comprises:incrementing the counter; andgenerating the updated temporary identifier using a key derivation function based on at least one of: the encryption key; the incremented counter; a device identifier of the wireless device; or the temporary identifier.12.The method of claim 11, wherein incrementing the counter comprises:in response to a lifecycle of the counter being reached, incrementing the counter.13.The method of claim 10, wherein the second message carries an updated random number, updating the temporary identifier comprising:generating the updated temporary identifier using a key derivation function based on at least one of: the encryption key; the updated random number; a device identifier of the wireless device; or the temporary identifier.14.The method of claim 13, wherein the updated random number carried in the second message is encrypted using the encryption key.15.The method of claim 10, wherein the temporary identifier is updated synchronously in the wireless device and the network element.16.The method of claim 10, wherein the second message carries an updated temporary identifier, updating the temporary identifier comprising: updating the temporary identifier with the updated temporary identifier.17.The method of claim 16, wherein the updated temporary identifier carried in the second message is encrypted using the encryption key.18.A method for wireless communication, performed by a network element, comprising:obtaining a temporary identifier of a wireless device; andreceiving, from a wireless device, a first message carrying the temporary identifier.19.The method of claim 18, wherein the wireless device comprises an Ambient Internet of Things (AIoT) device.20.The method of claim 18, wherein the first message further carries information collected or sensed by the wireless device from its surrounding environment.21.The method of claim 18, wherein communication between the wireless device and the network element is via a reader device, the reader device comprising at least one of: a User Equipment (UE) , or a base station.22.The method of claim 18, wherein the network element comprises a network function in a core network.23.The method of claim 18, further comprising performing an operation based on information carried by the first message.24.The method of any one of claims 18-23, wherein the wireless device is provisioned with at least one of following credential information that is synchronized with the network element:an initial temporary identifier;an encryption key;a counter; ora random number.25.The method of claim 24, wherein obtaining the temporary identifier comprises generating the temporary identifier using a key derivation function based on at least one of:the encryption key;the counter; orthe random number.26.The method of claim 24, further comprising:transmitting, to the wireless device, a second message as a response to the first message; andupdating the temporary identifier to obtain an updated temporary identifier.27.The method of claim 26, wherein updating the temporary identifier comprises:incrementing the counter; andgenerating the updated temporary identifier using a key derivation function based on at least one of: the encryption key; the incremented counter; a device identifier of the wireless device; or the temporary identifier.28.The method of claim 27, wherein incrementing the counter comprises:in response to a lifecycle of the counter being reached, incrementing the counter.29.The method of claim 26, wherein the second message carries an updated random number, updating the temporary identifier comprising:generating the updated temporary identifier using a key derivation function based on at least one of: the encryption key; the updated random number; a device identifier of the wireless device; or the temporary identifier.30.The method of claim 29, wherein the updated random number carried in the second message is encrypted using the encryption key.31.The method of claim 26, wherein the temporary identifier is updated synchronously in the wireless device and the network element.32.The method of claim 26, wherein the second message carries the updated temporary  identifier.33.The method of claim 32, wherein the updated temporary identifier carried in the second message is encrypted using the encryption key.34.A device or a network element comprising a memory for storing computer instructions and a processor in communication with the memory, wherein the processor, when executing the computer instructions, is configured to implement a method in any one of claims 1-33.35.A computer program product comprising a non-transitory computer-readable program medium with computer code stored thereupon, the computer code, when executed by one or more processors, causing the one or more processors to implement a method of any one of claims 1-33.

Images