Methods, devices, and systems for aiot device temporary identifier derivation in a communication network

Abstract

The present application generally relates to deriving and utilizing a temporary identifier of an AIoT device in wireless communication. The method is performed by the AIoT device, comprising: obtaining a temporary identifier of the wireless device; and sending a first message carrying the temporary identifier to a network element.

Description

Technical Field

[0001] This disclosure relates to wireless communications, and more particularly to deriving or obtaining identifiers for AIoT devices in wireless communication networks such as 4G, 5G and 6G wireless communication networks. Background Technology

[0002] Wireless communication systems involving mobile communication technologies (e.g., fifth-generation (5G) or further sixth-generation (6G)) are facing increasing demands, including systems deploying large numbers of Internet of Things (IoT) devices. Identifying legitimate IoT devices is crucial for allowing only authorized IoT devices to connect to communication networks. Developing an efficient, robust, and feasible authentication mechanism to accommodate a wide range of low-complexity, low-cost IoT devices is essential for facilitating their widespread deployment. Summary of the Invention

[0003] This disclosure describes methods, systems, devices, and storage media related to wireless communication, and in particular relates to deriving or obtaining identifiers of AIoT (Ambient Internet of Things) devices in wireless communication networks such as 4G, 5G, and 6G wireless communication networks.

[0004] In one embodiment, this disclosure describes a method for wireless communication. The method is performed by a wireless device, such as an AIoT device, and includes: acquiring a temporary identifier for the wireless device; and sending a first message carrying the temporary identifier to a network element.

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

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

[0007] In another embodiment, a computer program product is disclosed, comprising a non-transitory computer-readable program medium having computer code stored thereon. When the computer code is executed by a processor, it can cause the processor to implement any of the methods described above.

[0008] The above embodiments and other aspects and alternatives to their implementation are explained in more detail in the following drawings, description and claims. Attached Figure Description

[0009] Figure 1An exemplary communication network is shown, including various terminal devices, carrier networks, data networks, and service applications.

[0010] Figure 2 Exemplary network functions or network nodes in a communication network are shown.

[0011] Figure 3 An exemplary network function or network node in a wireless communication network is shown.

[0012] Figure 4 An exemplary network model for an authentication and key management (AKMA) framework for applications is shown.

[0013] Figure 5 An example wireless network node (or network element, network entity, entity, application function) is shown.

[0014] Figure 6 An example user device is shown.

[0015] Figures 7-8 An exemplary logic flow for configuring, synchronizing, and utilizing temporary identifiers for AIoT devices is shown. Detailed Implementation

[0016] Figure 1 An exemplary communication network, shown as 100, may include terminal devices 110 and 112, a carrier network 102, various service applications 140, and other data networks 150. For example, carrier network 102 may include access network 120 and core network 130. Carrier network 102 may be configured to transmit voice, data, and other information (collectively, data services) between terminal devices 110 and 112, between terminal devices 100 and 112 and service applications 140, or between terminal devices 110 and 112 and other data networks 150. Communication sessions and corresponding data paths may be established and configured for such data transmission. Access network 120 may be configured to provide network access to core network 130 to terminal devices 110 and 112. For example, access network 120 may support wireless or wired access via radio resources. Core network 130 may include various network nodes or network functions configured to control communication sessions and perform network access management and data service routing. Service application 140 can be hosted by various application servers, which terminal devices 110 and 112 can access through the core network 130 of the operator network 102. Service application 140 can be deployed as a data network outside the core network 130. Similarly, other data networks 150 can be accessed by terminal devices 110 and 112 through the core network 130 and can appear as a data destination or data source for a specific communication session instantiated in the operator network 102.

[0017] Figure 1 The core network 130 may include various geographically distributed and interconnected network nodes or functions to provide network coverage for the service area of ​​the operator 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 software entities. Each network node may be configured with one or more types of network functions. These network nodes or network functions may collectively provide configuration and routing functions for the core network 130. The terms "network node" and "network function" are used interchangeably in this disclosure.

[0018] Figure 2 An exemplary division of network functions in the core network 130 of the communication network 200 is also shown. Although Figure 2 Only a single instance of a network node or function is shown, but those skilled in the art will readily understand that each of these network nodes can be instantiated as multiple instances of network nodes distributed throughout the core network 130. Figure 2 As shown, 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. Figure 2 The various solid lines in the diagram indicate exemplary signaling and data exchanges between various types of network nodes through various communication interfaces. Such signaling and data exchanges can be carried out using signaling or data messages that conform to a predetermined format or protocol.

[0019] The above text is in Figure 1 and Figure 2 The implementation described herein can be applied to both wireless and wired communication systems. Figure 3 It shows the basis Figure 2 An exemplary cellular wireless communication network 300 is a general implementation of the communication network 200. Figure 3 The wireless communication network 300 is shown to include a user equipment (UE) 310 (used as...) Figure 2 Terminal equipment 110), Radio Access Network (RAN) 320 (used as terminal equipment 110), Radio Access Network (RAN) 320 Figure 2 Access network 120), data network (DN) 150, and core network 130, the core network 130 including access management function (AMF) 330 (used as... Figure 2 AMNN 230), Session Management Function (SMF) 340 (used as AMNN 230), Session Management Function (SMF) 340 Figure 2 SMNN 240), Application Function (AF) 390 (used as Figure 2 ADMNN 210), User Plane Function (UPF) 350 (used as Figure 2 DRNN 250), policy control function 322 (used as Figure 2 PCNN 220), Authentication Server Function (AUSF) 360 (used as Figure 2 AUNN 260) and Universal Data Management (UDM) function 370 (used as Figure 2 (UDMNN 270). Similarly, although Figure 3 Only a single instance of some network functions or nodes of the wireless communication network 300 (particularly the core network 130) is shown, but those skilled in the art will readily understand that each of these network nodes or functions can have multiple instances distributed throughout the wireless communication network 300. While AF 390 in Figure 3 While depicted as part of the core network 130, these functions can be considered associated with specific service applications 140 and can be considered external to the core network 140. In this disclosure, the various functions deployed in the wireless network as described above can also be referred to as functional entities, which can be implemented via hardware, software, or a combination thereof as network nodes, network elements, or logical functions.

[0020] exist Figure 3 In this context, UE 310 can be implemented as various types of mobile devices configured to access the core network 130 via RAN 320. UE 310 can include, but is not limited to, mobile phones, laptops, tablets, Internet of Things (IoT) devices, distributed sensor network nodes, wearable devices, etc. The UE can also be a UE with multi-access edge computing (MEC) capabilities that support edge computing. For example, RAN 320 can include multiple radio base stations distributed throughout the service area of ​​the operator network. Communication between UE 310 and RAN 320 can be carried over an over-the-air (OTA) radio interface, such as... Figure 3 As shown in 311.

[0021] Continue to refer to Figure 3 The UDM 370 can form a persistent storage or database for user contract and subscription data. The UDM can also include an authentication certificate repository and processing capabilities (ARPF, such as...). Figure 3 As shown in section 370, it is used to store long-term security credentials for user authentication and to perform calculations of encryption keys using these long-term security credentials as input, as described in more detail below. To prevent unauthorized exposure of UDM / ARPF data, UDM / ARPF 370 can be located in a secure network environment of a network operator or a third party.

[0022] The AMF / SEAF 330 can communicate with RAN 320, SMF 340, AUSF 360, UDM / ARPF 370, and Policy Control Function (PCF) 322 via various communication interfaces indicated by solid lines connecting these network nodes or functions. The AMF / SEAF 330 can handle UE-to-Non-Access Stratum (NAS) signaling management, UE 310 registration and access configuration to core network 130, and SMF 340 allocation to support specific UE communication needs. The AMF / SEAF 330 can also handle UE mobility management. The AMF may also include Security Anchoring Functions (SEAFs, such as...) Figure 3 As shown in section 330 (and described in more detail below), this function interacts with AUSF 360 and UE 310 for user authentication and management of encryption / decryption keys at various levels. AUSF 360 can terminate user registration / authentication / key generation requests from AMF / SEAF 330 and interact with UDM / ARPF 370 to complete such user registration / authentication / key generation.

[0023] The SMF 340 can be assigned by the AMF / SEAF 330 for a specific communication session instantiated in the wireless communication network 300. The SMF 340 can be responsible for allocating the UPF 350 to support communication sessions and data flows within the user data plane, and for configuring / regulating the allocated UPF 350 (e.g., for developing packet detection and forwarding rules for the allocated UPF 350). In addition to being allocated by the SMF 340, the UPF 350 can also be allocated by the AMF / SEAF 330 for specific communication sessions and data flows. The UPF 350, allocated and provided by the SMF 340 and AMF / SEAF 330, can be responsible for data routing and forwarding, and for reporting network usage for specific communication sessions. For example, the UPF 350 can be responsible for routing end-to-end data flows between UE 310 and DN 150, and between UE 310 and service application 140. DN 150 and service application 140 may include, but are not limited to, data networks and services provided by operators of wireless communication networks 300 or third-party data networks and service providers.

[0024] PCF 322 can manage and provide AMF / SEAF 330 and SMF 340 with policies and rules at various levels applicable to communication sessions associated with UE 310. Therefore, for example, AMF / SEAF 330 can assign SMF 340 to a communication session based on the policies and rules associated with UE 310 and obtained from PCF 322. Similarly, SMF 340 can assign UPF 350 to handle data routing and forwarding for the communication session based on the policies and rules obtained from PCF 322.

[0025] Although Figures 1-3 The various exemplary implementations described below are based on cellular wireless communication networks, but the scope of this disclosure is not limited thereto, and its basic principles are applicable to other types of wireless and wired communication networks.

[0026] Figure 3 Network identification and data security in the wireless communication network 300 can be managed via user authentication processes provided by AMF / SEAF 330, AUSF360, and UDM / ARPF 370. Specifically, UE 310 can first communicate with AMF / SEAF330 for network registration, and then be authenticated by AUSF360 based on the user contract and subscription data in UDM / ARPF 370. The communication session established for UE 310 after user authentication with the wireless communication network 300 can then be protected by various levels of encryption / decryption keys. The generation and management of these keys can be coordinated by AUSF 360 and other network functions within the communication network 300.

[0027] AKMA framework In wireless communication networks, application functions (AFs or application function entities) can provide application services to UEs. AFs can be deployed in various locations, such as the UE's home public land mobile network (HPLMN), the UE's visited public land mobile network (VPLMN) (e.g., when the UE roams to a VPLMN), or data networks (DNs) outside the HPLMMN and VPLMN. Secure or encrypted data communication between the AF and the UE can be implemented within an application authentication and key management (AKMA) framework. The AKMA framework can be based on various authentication processes, such as the 5G Authentication and Key Negotiation (5G-AKA) method, the Extensible Authentication Protocol with Key Negotiation 3rd Generation (EAP-AKA) method, the Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) method, and so on.

[0028] Figure 4 An exemplary network model 400 for implementing the AKMA framework is shown. This model includes various network elements. Each network element can be implemented as a physical or logical entity providing a specific set of network functions. Logical entities can be based on software, hardware, firmware, or any combination thereof. For example, a logical entity may include a server providing that functionality. Alternatively, a logical entity may be implemented based on a cloud-based service or platform, such as Software as a Service (SaaS), Platform as a Service (PaaS), etc.

[0029] The AKMA anchoring function (AAnF) 412 provides secure anchoring functionality in the HPLMN. AAnF stores the AKMA anchoring key (KAKMA) associated with the UE 424 for the AKMA service, which is received from the Authentication Server Function (AUSF) 416 after the UE 424 completes successful master authentication. AAnF can also generate key material to be used between the UE and the Application Function (AF) 420 and maintain the UE AKMA context (also known as the AKMA security context).

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

[0031] AF 420 can provide application services to the UE. Under the AKMA framework, AF can use K AKMA The identifier requests its AKMA application key from AAnF, denoted as K. AF This identifier may include the AKMA key identifier (A-KID). AAnF can only provide the AF with the key identifier after the AF has been authenticated and authorized by the operator's network. AF The AF can be located inside or outside the operator's network. In this disclosure, for simplicity, the AKMA application key (denoted as KAF or K) is used. AF It can also be called the AF key.

[0032] In some example implementations, A-KID may include: A-TID (AKMA temporary UE identifier) ​​and HN-ID (home network identifier). A-KID identifies the UE's K... AKMA Key. The A-KID can be in the format of Network Access Identifier (NAI), i.e., username@realm. Specifically, the username part can include the UE's Routing Identifier (RID) and AKMA Temporary UE Identifier (A-TID), and the realm part can include the Home Network Identifier.

[0033] A-TID can be derived from the UE's KAUSF and SUPI (Subscription Persistent Identifier). For example, A-TID = KDF("A-TID", SUPI, K... AUSF ), where KDF is the key derivation function.

[0034] The Network Exposure Function (NEF) 410 can be configured to enable and authorize external AFs to access the AKMA service and forward AKMA service requests to AAnFs. If multiple AAnFs exist, the NEF can also perform AAnF selection.

[0035] AUSF 416 can provide AAnF with the UE's Subscription Permanent Identifier (SUPI) and AKMA key materials (e.g., A-KID, K...). AKMA AUSF can also perform AAnF selection.

[0036] UDM can store AKMA subscription data of subscribers (or UEs subscribing to wireless communication networks).

[0037] refer to Figure 4 The AKMA framework may involve various interfaces. These interfaces may include Nnef, Naanf, Nudm, Uausf, and Namf, which can be called service-based interfaces (SBIs) because each interface corresponds to a service provided by a network element. For example, Nnef represents an SBI used by the NEF; Naanf represents an SBI used by the AAnF; and Nudm represents an SBI used by the UDM. Network elements can interact with each other through various SBIs. SBIs can provide security protection. For example, SBIs may be protected against confidentiality, integrity, and replay attacks.

[0038] Figure 4 The diagram illustrates an implementation of AAnF deployed as a standalone function. Other deployment options are available. For example, AAnF can be located in the same location as AUSF, or it can be located in the same location as NEF.

[0039] Figure 5 Examples of electronic devices 500 are shown for implementing various network functions (NFs), network nodes, network elements, network entities such as network base stations (e.g., radio access network nodes), core networks (CNs), core network elements / entities / nodes (e.g., AMF, UDM, AAnF, etc.), operations and maintenance (OAM), etc. Optionally, in one implementation, the example electronic device 500 may include radio transmit / receive (Tx / Rx) circuitry 508 to transmit / receive communications with the UE and / or other base stations. Optionally, in one implementation, the electronic device 500 may also include network interface circuitry 509 to enable the base station to communicate with other base stations and / or the core network, such as optical or wired interconnects, Ethernet, and / or other data transmission media / protocols. The electronic device 500 may optionally include input / output (I / O) interfaces 506 for communicating with operators, etc.

[0040] Electronic device 500 may also include system circuitry 504. System circuitry 504 may include processor 521 and / or memory 522. Memory 522 may include operating system 524, instructions 526, and parameters 528. Instructions 526 may be configured to cause one or more processors 521 to perform the functions of a network node. Parameters 528 may include parameters that support the execution of instructions 526. For example, parameters may include network protocol settings, bandwidth parameters, radio frequency mapping allocation, and / or other parameters.

[0041] In this disclosure, network functions / network entities / entities, such as network functions (NF), AMF, AUSF, UDM, AAnF, NEF, AF, can be implemented in hardware, software, or a combination of hardware and software, and can be implemented or integrated in electronic device 500. They can also be implemented as logical entities hosted by electronic device 500.

[0042] Figure 6 Examples of electronic devices implementing terminal device 600 (e.g., AIoT devices, UEs, etc.) are shown. Device 600 may be a mobile device, such as a smartphone or mobile communication module installed in a vehicle. Device 600 may include some or all of the following: communication interface 602, system circuitry 604, input / output interface (I / O) 606, display circuitry 608, and memory 609. The display circuitry may include a user interface 610. System circuitry 604 may include any combination of hardware, software, firmware, or other logic / circuit. System circuitry 604 may be implemented, for example, using one or more system-on-chip (SoC), application-specific integrated circuit (ASIC), discrete analog and digital circuitry, and other circuitry. System circuitry 604 may be part of the implementation of any desired functionality in device 600. In this regard, system circuitry 604 may include logic to facilitate the decoding and playback of music and video, such as MP3, MP4, MPEG, AVI, FLAC, AC3, or WAV decoding and playback; run applications; accept user input; save and retrieve application data; establish, maintain, and terminate cellular phone calls or data connections, such as internet connections; establish, maintain, and terminate wireless network connections, Bluetooth connections, or other connections; and display relevant information on user interface 610. User interface 610 and input / output (I / O) interface 606 may include a graphical user interface, a touch-sensitive display, haptic feedback or other haptic outputs, voice or facial recognition inputs, buttons, switches, speakers, and other user interface elements. Other examples of I / O interface 606 may include microphones, video and still image cameras, temperature sensors, vibration sensors, rotation and orientation sensors, headphone and microphone input / output jacks, universal serial bus (USB) connectors, memory card slots, radiation sensors (e.g., IR sensors), and other types of inputs.

[0043] Reference Figure 6 The communication interface 602 may include radio frequency (RF) transmitting (Tx) and receiving (Rx) circuitry 616 that processes the transmission and reception of signals via one or more antennas 614. The communication interface 602 may include one or more transceivers. The transceiver may be a wireless transceiver that includes modulation / demodulation circuitry, a digital-to-analog converter (DAC), a shaping table, an analog-to-digital converter (ADC), filters, waveform shapers, preamplifiers, power amplifiers, and / or other logic for transmission and reception via one or more antennas or (for some devices) via a physical (e.g., wired) medium. The transmitted and received signals may conform to any of various formats, protocols, modulations (e.g., QPSK, 16-QAM, 64-QAM, or 256-QAM), frequency channels, bit rates, and encodings. As a specific example, the communication interface 602 may include a transceiver supporting transmission and reception under 2G, 3G, BT, WiFi, Universal Mobile Telecommunications System (UMTS), High-Speed ​​Packet Access (HSPA)+, 4G / LTE, 5G, and 6G standards. However, the techniques described below are applicable to other wireless communication technologies, whether from the 3rd Generation Partnership Project (3GPP), the GSM Association, 3GPP2, IEEE, or other partners or standards bodies.

[0044] Reference Figure 6 System circuitry 604 may include one or more processors 621 and memory 622. Memory 622 stores, for example, an operating system 624, instructions 626, and parameters 628. Processor 621 is configured to execute instructions 626 to achieve the desired functionality of device 600. Parameters 628 can provide and specify configuration and operational options for instructions 626. Memory 622 may also store any BT, WiFi, 3G, 4G, 5G, 6G, or other data that device 600 will send or has received via communication interface 602. In various implementations, system power for device 600 may be provided by energy storage devices such as batteries or transformers.

[0045] Note that in this disclosure, AIoT devices may implement only a portion of the hardware and / or software components of Device 600 to achieve a design goal of ultra-low complexity.

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

[0047] Ambient IoT devices are significantly cheaper than previous generations of IoT devices, such as NB-IoT (Narrowband IoT), CIoT (Consumer IoT), and RedCap (Red Cap) IoT devices. For example, AIoT devices can have the ability to harvest energy from radio waves through a process called AIoT energy harvesting, which involves utilizing the power present in ambient radio waves to power the device.

[0048] While AIoT technology is considered a key driver of cost-effective solutions and will revolutionize how information is tracked, monitored, and managed, it also presents unique challenges that must be addressed. One of the main challenges relates to the ultra-low complexity design of AIoT devices, characterized by very limited hardware / software capabilities and stringent power and resource constraints (such as memory). This design approach, while crucial for cost-effectiveness and long-term operability, imposes limitations on the computing power, memory resources, and available energy of AIoT devices. Therefore, existing traditional security models, such as subscription models, may not be suitable for AIoT devices. New mechanisms may need to be adapted to accommodate the resource-constrained characteristics of AIoT devices to achieve a balance between robust security, efficient information exchange (e.g., with the core network), and energy optimization.

[0049] Various embodiments are described in this disclosure to protect sensitive AIoT device identification information, for example, when the AIoT device is under the control of an operator.

[0050] In this disclosure, the permanent subscriber identifier is not allowed to be sent in plaintext via the Uu interface (i.e., the air interface). For example, when the UE is paged, only the temporary identifier of the AIoT device is sent in plaintext via the Uu interface, and the temporary identifier is only allowed to be used a predefined number of times (e.g., the temporary identifier is only allowed to be used once).

[0051] Specifically, the embodiments in this disclosure are based on at least one of the following assumptions: • AIoT devices are more complex than RFID tags that only reflect a pre-configured device ID, but far less complex than other types of 3GPP IoT devices, such as NB-IoT, CIoT, and RedCap IoT devices.

[0052] • AIoT devices have non-volatile storage capabilities.

[0053] • AIoT devices may support a lightweight Temp ID generation algorithm, which generates Temp IDs sufficient to avoid tracking by unauthorized AIoT devices.

[0054] In this disclosure, the permanent identifier of an AIoT device (e.g., device ID) is protected as sensitive information to maintain privacy and prevent security vulnerabilities, and is not permitted to be transmitted via the Uu interface. Instead, an alternative AIoT device identifier is introduced. In some example implementations, this newly introduced alternative AIoT device identifier may differ from various other existing UE identifiers in the wireless standard, such as Subscription Hidden 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 the temporary identifier (TempID) of the AIoT device.

[0055] TempID may have the following characteristics: First, TempID is synchronized between AIoT devices and the core network (CN). If the TempID is not synchronized between the CN network function (NF) and the AIoT device, the CN NF and AIoT may need to resynchronize the TempID.

[0056] Second, as the name suggests, TempID is refreshed frequently. For example, it can be updated / refreshed after a predefined number of uses (e.g., after n transmissions via the air interface), where n is an integer. In some example implementations, n equals 1, meaning that TempID is refreshed every time it is sent via the air interface. TempID refreshes are synchronized between the core network and AIoT devices.

[0057] For example, TempID may have a predefined lifecycle, and it should be updated / refreshed once the lifecycle is reached.

[0058] Third, TempID is encrypted using the TempID derivation function, an encryption key, and the input string. Encryption may include keys under the AKMA framework or other types of security frameworks, such as AMF keys (K... AMF ), AUSF key (K AUSFAlternatively, it can be another long-term pre-configured key. The input string for the derivation function can be based at least in part on the fixed device ID of the AIoT device and some other parameters, such as a counter or a random number. More details about TempID derivation will be described later in this disclosure.

[0059] In this disclosure, the core network (CN) may refer to CN network functions (NF), CN nodes, etc. The core network NF may include, for example, independent network functions, network functions or authentication functions co-located with other functions within the core network (such as AMF, AUSF, UDM).

[0060] In some example implementations, an initial TempID can be provided on both the CN NF and the AIoT device. Specifically, the initial TempID of the AIoT device can be configured via a network access procedure (to bring the AIoT device into the core network) or a registration procedure (to register the AIoT device with the core network). This configuration can be performed by the CN NF. Alternatively, additional initial credential parameters can be configured for the AIoT device, which can be used to derive the TempID (including both the initial TempID and subsequently refreshed TempIDs).

[0061] In some example implementations, during the network access process (to bring an AIoT device to the network), the CN NF can retrieve information from another NF or AF (Application Function) to bring the AIoT device to the network. For example, the CN NF can establish an IP connection with the AF based on a URL (Uniform Resource Locator) and / or FQDN (Fully Qualified Domain Name) associated with the AF, which stores additional network access information for the AIoT device.

[0062] Example 1 In this embodiment, the AIoT device may have hardware and / or software capabilities to perform identifier derivation to obtain the AIoT TempID. This capability allows the AIoT device to independently generate or obtain its TempID.

[0063] To maintain synchronization with TempID, both AIoT devices and the core network participate in the synchronized AIoT TempID update process. See below for reference. Figure 7 The exemplary steps for generating and utilizing AIoT TempIDs are described in detail. An exemplary method may include some or all of the following steps.

[0064] Prerequisites (Step 0): As a prerequisite, AIoT devices are synchronized with the core network (CN) (e.g., CN nodes, CN NF) relative to the initial credential information.

[0065] Initial credential information may include an initial temporary identifier (TempID). Alternatively, initial credential information may include at least one of the following: • The encryption key used to generate TempID; • Random number; or • Initial counter.

[0066] For example, the initial counter value can be set to 0 or another predefined number.

[0067] Initial credential information can be provided to AIoT devices and / or the CN side (e.g., CN node, CN NF) in at least one of the following ways: • The network access process or registration process for AIoT devices within the core network; or • Non-access stratum (NAS) program or access stratum (AS) program.

[0068] Step 1: If no initial TempID is provided in step 0, the AIoT device and the core network can generate an initial TempID in parallel using the TempID derivation function with an encryption key and various input parameters. The derivation function will be described in more detail later.

[0069] Step 2: When an 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 can send an AIoT message to the reader. An AIoT message may include the information to be reported (more specifically, AIoT information) and the AIoT device's TempID.

[0070] For example, an AIoT device can 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 humidity levels. If the AIoT device detects that certain conditions are met or exceeded—for example, if the temperature exceeds a predefined threshold or the humidity level rises above a certain limit—the device is programmed to trigger a service message. This service message serves as an alarm or notification, indicating that the monitored environmental conditions have met predetermined criteria, thereby prompting the core network to take appropriate action or response as deemed necessary.

[0071] In some example implementations, the reader can be viewed as a relay or proxy between the AIoT device and the core network. The reader may include, for example, a UE or base station. Specifically, the UE or base station may be located near the AIoT device, enabling the AIoT device to transmit and / or receive signals with low power requirements.

[0072] Step 3: The reader can forward AIoT messages to the core network.

[0073] Step 4: The core network can use the TempID carried in the AIoT message to identify a specific AIoT device and execute the corresponding operation indicated by the AIoT message. The core network can verify the validity of an AIoT device based on the TempID. For example, the core network can 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.

[0074] Alternatively, as an additional layer of security, the core network can further enhance the verification process by verifying additional subscription data of AIoT devices.

[0075] Step 5: The core network can respond to AIoT messages by acknowledging the reader.

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

[0077] Step 6: The reader can forward confirmations to AIoT devices.

[0078] Step 7: In this step, the AIoT device and the core network perform a resynchronization process to update the AIoT device's TempID. This involves generating a new, refreshed, or updated TempID using the TempID derivation function for subsequent communication. Specifically, both the AIoT device and the core network can perform the TempID derivation function independently.

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

[0080] This article describes an exemplary TempID derivation function. The TempID derivation function can utilize an encryption key (i.e., the TempID generation key) as an input key. The encryption key can include keys under the AKMA framework, such as AMF keys (K... AMF ), AUSF key (K AUSFAlternatively, another type of long-term key can be pre-configured in the AIoT device and core network side (e.g., CN NF). For example, the encryption key can be 256 bits. The following equation can be used to form the input string S for the TempID derivation function: S = FC || P0 || L0 || P1 || L1 || P2 || L2 || ... || Pn || Ln in: "||" is the concatenation operator, and n is an integer.

[0081] FC is used to distinguish different instances of the algorithm. FC can be a single octet or two octets in the form of FC1||FC2.

[0082] P0 ... Pn are n+1 input parameters, and L0 ... Ln is a two-byte representation of the length of the corresponding input parameter encoding P0 ... Pn.

[0083] For example, the input parameters can be set as follows: FC = a predefined number; P0="TempID". That is, the current TempID can be used as part of the input to derive the refreshed TempID.

[0084] L0 = the length of "TempID"; (e.g., 0x00 0x06); P1 = Device ID. The Device ID is a fixed, unique identifier assigned to an AIoT device. The Device ID can also be a universally unique ID.

[0085] L1 = Length of the device ID; P2 = Random number or counter; L2 = length of the random number or counter.

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

[0087] In some example implementations, the reader can act as a central hub for generating TempIDs. Specifically, the reader can derive refreshed TempIDs based on a refreshed random number (from the core network) or an incrementing counter. The reader can then send the refreshed TempIDs to AIoT devices and the core network.

[0088] Please note that various timings for incrementing the counter on each side (AIoT and core network) can be supported. For example, the AIoT device can increment the counter at one of the following times: 1) after an AIoT message is transmitted; or 2) when an acknowledgment is received from the core network.

[0089] In this embodiment, for example, once the 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 carrying the TempID is received (e.g., in step 3), it will trigger the CN side to refresh the TempID of the AIoT device.

[0090] Example 2: In this embodiment, the core network assumes the primary responsibility for driving the TempID inference and distribution process, thereby reducing the computational burden on AIoT devices to calculate and refresh TempIDs. This centralized approach offloads the TempID inference task from potentially resource-constrained AIoT devices. See below for reference. Figure 8 The exemplary steps for generating and utilizing AIoT TempIDs are described in detail. An exemplary method may include some or all of the following steps.

[0091] Prerequisites (Step 0): As a prerequisite, AIoT devices are synchronized with the core network (CN) (e.g., CN nodes, CN NF) relative to the initial credential information, including the initial temporary identifier (TempID).

[0092] Initial credential information can be provided to AIoT devices and / or the CN side (e.g., CN node, CN NF) in at least one of the following ways: • The network access process or registration process for AIoT devices within the core network; or • Non-access stratum (NAS) program or access stratum (AS) program.

[0093] Step 1: When an 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 can send an AIoT message to the reader. The AIoT message may include the information to be reported and the AIoT device's TempID.

[0094] In some example implementations, the reader can be viewed as a relay or proxy between the AIoT device and the core network. The reader may include, for example, a UE or base station. Specifically, the UE or base station may be located near the AIoT device, enabling the AIoT device to transmit and / or receive signals with low power requirements.

[0095] Step 2: The reader can forward AIoT messages to the core network.

[0096] Step 3: The core network can use the TempID carried in the AIoT message to identify a specific AIoT device and execute the corresponding operation indicated by the AIoT message. The core network can verify the validity of an AIoT device based on the TempID. For example, the core network can verify the received TempID against a database of registered and authorized AIoT devices to ensure that the TempID corresponds to a legitimate AIoT device.

[0097] Alternatively, as an additional layer of security, the core network can further enhance the verification process by verifying additional subscription data of AIoT devices.

[0098] The core network can generate new, refreshed, or updated TempIDs based on the TempID derivation function for subsequent communication.

[0099] If a random number is used to generate the TempID, the core network can generate a new / refreshed random number. If a counter is used to generate the TempID, the core network increments the current counter by n to obtain a refreshed counter. The core network then uses this refreshed counter to derive a new TempID, where n is an integer. In some example implementations, n equals 1.

[0100] The details of generating the refreshed TempID using the TempID derivation function can be found in the previous embodiments and are omitted here for simplicity.

[0101] Step 4: The core network can respond to AIoT messages using acknowledgments of the reader. The response message can carry a refreshed TempID generated by the core network.

[0102] Step 5: The reader can forward a response message carrying a refreshed TempID to the AIoT device. The AIoT device can then update its TempID based on the response message.

[0103] In this embodiment, for example, once the TempID of the AIoT device is exposed to the air interface (e.g., in steps 1-2), it will trigger a CN 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.

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

[0105] In some further embodiments, as an additional security layer, credential information such as TempID and / or random numbers transmitted between the AIoT device and the core network can be encrypted, for example, with an encryption key (e.g., as specified in step 0 or in previous embodiments).

[0106] An exemplary method performed by a wireless device, according to embodiments of this disclosure, may include obtaining a temporary identifier of the wireless device; and sending a first message carrying the temporary identifier to a network element.

[0107] In any part or combination of the above implementations, the wireless device includes an AIoT device.

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

[0109] In any part or combination of the above implementations, communication between the wireless device and the network element is carried out via a reader device, which includes at least one of the UE or the base station.

[0110] In any part or combination of the above implementations, network elements include network functions in the core network.

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

[0112] In any part or combination of the above implementation, the encryption key includes at least one of the following: a wireless device-specific AMF key Kamf; or a wireless device-specific AKMA Authentication Server Function (AUSF) key Kausf.

[0113] In this disclosure, message type and / or message name (e.g., such as Figures 7-8 (As shown) are for illustrative purposes only. Different message types and / or message names may be chosen in implementations, and should still be included in this disclosure as long as the underlying principles are the same, for example, if the messages are used for the same purpose.

[0114] In this disclosure, a single information element in a message can be broken down into multiple information elements. Multiple information elements can also be combined into a single information element.

[0115] In this disclosure, the steps in each embodiment are for illustrative purposes only, and other alternatives can be derived based on the disclosed embodiments as needed. Some steps described in the embodiments may be optional, while others provide alternative parallel solutions to other steps. For example, only some steps may need to be performed. For another example, the order of steps may be adjusted. For another example, several steps may be combined (e.g., several messages may be combined into one message). For another example, a single step may be split (e.g., a message may be sent via two sub-messages).

[0116] The accompanying drawings and description provide specific example embodiments and implementations. However, the described subject matter can be embodied in a variety of different forms, and therefore, the covered or claimed subject matter is intended to be construed as not being limited to any of the example embodiments described herein. A reasonably broad scope is intended for the claimed or covered subject matter. In addition, for example, the subject matter can be embodied as a method, apparatus, component, system, or non-transitory computer-readable medium for storing computer code. Thus, for example, embodiments can take the form of hardware, software, firmware, storage media, or any combination thereof. For example, the above-described method embodiments can be implemented by a component, apparatus, or system including a memory and a processor, by executing computer code stored in the memory.

[0117] Throughout the specification and claims, terms may have subtle meanings implied or implied in the context that go beyond their expressly defined meanings. Similarly, 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 different embodiments. For example, the claimed subject matter includes combinations of all or some of the exemplary embodiments.

[0118] Generally, terms can be understood, at least in part, from their usage in context. For example, terms used herein, such as “and,” “or,” or “and / or,” may include a variety of meanings that may depend, at least in part, on the context in which they are used. Typically, “or,” if used to relate a list such as A, B, or C, means A, B, and C, which is inclusive in this context, and A, B, or C, which is exclusive in this context. Furthermore, the term “one or more,” as used herein, depends, at least in part on the context and can be used to describe any feature, structure, or characteristic in a singular sense, or a combination of features, structures, and characteristics in a plural sense. Similarly, terms such as “a,” “one,” or “the” can be understood to convey either a singular or plural usage, at least in part on the context. Moreover, the word “based on” may be understood not necessarily to convey an exclusive set of factors, but may allow for the presence of other factors that are not necessarily explicitly described, at least in part on the context.

[0119] References to features, advantages, or similar language throughout this specification do not imply that all features and advantages achievable with this solution should be included in any single implementation thereof. Rather, references to features and advantages are understood to mean that a particular feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of this solution. Therefore, throughout this specification, discussions of features and advantages, and similar language, may, but do not necessarily, refer to the same embodiments.

[0120] Furthermore, the features, advantages, and characteristics described herein can be combined in any suitable manner in one or more embodiments. Based on the description herein, those skilled in the art will recognize that this solution can be practiced without one or more specific features or advantages of a particular embodiment. In other instances, those skilled in the art will recognize that in some embodiments, these features may not appear in all embodiments of this solution.

Claims

1. A method for wireless communication, the method being performed by a wireless device, comprising: Obtain the temporary identifier of the wireless device; as well as Send a first message carrying the temporary identifier to the network element.

2. The method according to claim 1, wherein, The wireless devices include Ambient Internet of Things (AIoT) devices.

3. The method according to claim 1, wherein, The first message also carries information collected or sensed by the wireless device from its surrounding environment.

4. The method according to claim 1, wherein, The communication between the wireless device and the network element is carried out via a reader device, which includes at least one of the following: a user equipment (UE) or a base station.

5. The method according to claim 1, wherein, The network elements include network functions in the core network.

6. The method according to any one of claims 1 to 5, wherein, The wireless device is provided with at least one of the following credential information synchronized with the network element: Initial temporary identifier; Encryption key; Counter; or Random number.

7. The method according to claim 6, wherein, The credential information is provided via at least one of the following: The network access process for the wireless device; The registration process for the wireless device; Non-Access Stratum (NAS) process; or Access layer (AS).

8. The method according to any one of claims 6 to 7, wherein, The encryption key includes at least one of the following: The AMF (Access Management Function) key Kamf is specific to the wireless device. or AKMA (Application Authentication and Key Management) Authentication Server Function (AUSF) key Kausf, which is specific to the wireless device.

9. The method according to any one of claims 6 to 7, wherein, Obtaining the temporary identifier includes generating the temporary identifier using a key derivation function based on at least one of the following: Encryption key; Counter; or Random number.

10. The method according to any one of claims 6 to 7, further comprising: Receive a second message from the network element as a response to the first message; as well as Update the temporary identifier to obtain an updated temporary identifier.

11. The method according to claim 10, wherein, Updating the temporary identifier includes: Increment the counter; and The updated temporary identifier is generated using a key derivation function based on at least one of the following: an encryption key; an incrementing counter; the device identifier of the wireless device; or a temporary identifier.

12. The method according to claim 11, wherein, The incrementing counter includes: In response to reaching the end of the counter's lifespan, the counter is incremented.

13. The method according to claim 10, wherein, The second message carries an updated random number, and updating the temporary identifier includes: The updated temporary identifier is generated using a key derivation function based on at least one of the following: an encryption key; an updated random number; the device identifier of the wireless device; or a temporary identifier.

14. The method according to claim 13, wherein, The updated random number carried in the second message is encrypted using the encryption key.

15. The method according to 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, and updating the temporary identifier includes: updating the temporary identifier using the updated temporary identifier.

17. The method according to claim 16, wherein, The updated temporary identifier carried in the second message is encrypted using the encryption key.

18. A method for wireless communication, the method being performed by a network element, comprising: Obtain the temporary identifier of the wireless device; as well as Receive a first message carrying the temporary identifier from the wireless device.

19. The method according to claim 18, wherein, The wireless devices include Ambient Internet of Things (AIoT) devices.

20. The method according to claim 18, wherein, The first message also carries information collected or sensed by the wireless device from its surrounding environment.

21. The method according to claim 18, wherein, The communication between the wireless device and the network element is carried out via a reader device, which includes at least one of the following: a user equipment (UE) or a base station.

22. The method according to claim 18, wherein, The network elements include network functions in the core network.

23. The method of claim 18, further comprising performing an operation based on information carried by the first message.

24. The method according to any one of claims 18 to 23, wherein, The wireless device is provided with at least one of the following credential information synchronized with the network element: Initial temporary identifier; Encryption key; Counter; or Random number.

25. The method according to claim 24, wherein, Obtaining the temporary identifier includes generating the temporary identifier using a key derivation function based on at least one of the following: Encryption key; Counter; or Random number.

26. The method of claim 24, further comprising: Send a second message to the wireless device as a response to the first message; as well as Update the temporary identifier to obtain an updated temporary identifier.

27. The method according to claim 26, wherein, Updating the temporary identifier includes: Increment the counter; and The updated temporary identifier is generated using a key derivation function based on at least one of the following: an encryption key; an incrementing counter; the device identifier of the wireless device; or a temporary identifier.

28. The method according to claim 27, wherein, The incrementing counter includes: In response to reaching the end of the counter's lifespan, the counter is incremented.

29. The method according to claim 26, wherein, The second message carries an updated random number, and updating the temporary identifier includes: The updated temporary identifier is generated using a key derivation function based on at least one of the following: an encryption key; an updated random number; the device identifier of the wireless device; or a temporary identifier.

30. The method according to claim 29, wherein, The updated random number carried in the second message is encrypted using the encryption key.

31. The method according to claim 26, wherein, The temporary identifier is updated synchronously in the wireless device and the network element.

32. The method according to claim 26, wherein, The second message carries the updated temporary identifier.

33. The method according to claim 32, wherein, The updated temporary identifier carried in the second message is encrypted using the encryption key.

34. A device or network element comprising a memory for storing computer instructions and a processor communicating with the memory, wherein, The processor is configured to implement the method of any one of claims 1 to 33 when executing the computer instructions.

35. A computer program product comprising a non-transitory computer-readable program medium having computer code stored thereon, which, when executed by one or more processors, causes the one or more processors to perform the method of any one of claims 1 to 33.

Images