Method, device and system for AIOT device authentication in communication networks

Abstract

This disclosure generally relates to security management for AIoT system. One method performed by a wireless device includes: receiving from a first network element a first message carrying at least one of: a first MAC; a device ID or a portion of the device ID of the wireless device; a first random number; or a first counter reset indicator indicating that a network side counter is reset; calculating via a hash function, a second MAC using at least one of following input: a key of the wireless device; the device ID of the wireless device; the portion of the device ID of the wireless device; an ID of a first network element; the first random number; or a device side counter that is maintained by the wireless device; and determining whether the first MAC is valid or not by comparing the first MAC and the second MAC.

Description

METHOD, DEVICE AND SYSTEM FOR AIOT DEVICE AUTHENTICATION IN COMMUNICATION NETWORKSTECHNICAL FIELD

[0001] This disclosure relates to wireless communication, and in particular, to security management for Ambient Internet of Things (AIoT, to A-IOT) system 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 relate to wireless communication, and in particular, to security management for AIoT system 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, the method includes: receiving a first message from a first network element, the first message carrying at least one of: a first Message Authentication Code (MAC) ; a device ID of the wireless device; a portion of the device ID of the wireless device; a first random number; or a first counter reset indicator  indicating that a network side counter is reset to an initial value; calculating via a hash function, a second MAC using at least one of following input: a key of the wireless device; the device ID of the wireless device; the portion of the device ID of the wireless device; an ID of a first network element which is in communication with the wireless device; the first random number; or a device side counter that is maintained by the wireless device; and determining whether the first MAC is valid or not by comparing the first MAC and the second MAC.

[0005] In another embodiment, a method for wireless communication is disclosed. Performed by a first network element, the method includes: calculating via a hash function, a first Message Authentication Code (MAC) for an Ambient Internet of Things (AIoT) device, using at least one of following input: a key of the AIoT device; a device identifier (ID) of the AIoT device; a portion of the device ID of the AIoT device; an ID of a second network element which is in communication with the AIoT device; a first random number; or a network side counter, wherein the network side counter is synchronized with a device side counter that is maintained by the AIoT device; and transmitting, to the second network element identified by the ID of the second network element, a first message carrying at least one of: the first MAC; the device ID of the AIoT device; the portion of the device ID of the AIoT device; the first random number; or a first counter reset indicator indicating that the network side counter is reset to an initial value.

[0006] In another embodiment, a method for wireless communication is disclosed. Performed by a first network element, the method includes: receiving, from a second network element, a first message comprising at least one of: a device ID of an Ambient Internet of Things (AIoT) device; a portion of the device ID of the AIoT device; a key of the AIoT device; calculating via a hash function, a first Message Authentication Code (MAC) for the AIoT device, using at least one of following input: the key of the AIoT device; the device ID of the AIoT device; the portion of the device ID of the AIoT device; an ID of a first network element; a first random number generated by the first network element; or a network side counter; and transmitting, to the AIoT device, a second message comprising at least one of:  the first MAC; the device ID of the AIoT device; the portion of the device ID of the AIoT device; the first random number; or a first counter reset indicator indicating that a network side counter is reset to an initial value.

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

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

[0009] 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

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

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

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

[0013] FIG. 4A shows an exemplary AIoT system architecture.

[0014] FIG. 4B shows another exemplary AIoT system architecture.

[0015] FIG. 4C shows another exemplary AIoT system architecture with an AIoT Device Management entity deployed.

[0016] FIG. 4D shows another exemplary AIoT system architecture with an AIoT Device Security Management entity deployed.

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

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

[0019] FIGs. 7-12 show various exemplary logic flow for authenticating service messages in an AIoT system.DETAILED DESCRIPTION

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

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

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

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

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

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

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

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

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

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

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

[0031] AIoT Device and AIoT System Architecture

[0032] Ambient IoT (AIoT, or A-IoT) 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.

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

[0034] Various deployment options are supported for AIoT system.

[0035] FIG. 4A shows an example AIoT system architecture. In this deployment, an independent reader is used. The reader may include a stand alone base station. In FIG. 4A, interfaces between various network elements are illustrated. For example, A-Uu interface connects the AIoT device and the reader, and A-RC interface connects the reader and the AIoT controller.

[0036] FIG. 4B shows another example AIoT system architecture. In this deployment, the reader may be co-located with a 3GPP UE, so that the communication between reader and AIoT controller uses a Packet Data Unit (PDU) session. In FIG. 4B, interfaces between various network elements are illustrated. For example, A-Uu interface connects the AIoT device and the reader, A-RC interface connects the reader and the AIoT controller, Uu interface connects the UE and the NG-RAN (Next Generation Radio Access Network) , and  A-CA interface connects the AIoT controller and the AF (Application Function) .

[0037] The A-Uu interface in FIGs. 4A-4B is an air interface in which wireless signal is used.

[0038] The reader may support following functions:

[0039] ● Supports the A-Uu air interface towards Ambient IoT Devices.

[0040] ● Registers with an AIoT Controller.

[0041] ● Supports the following functionality based on requests from an AIoT Controller:

[0042] ○ Perform one-time or periodic Inventory, deliver Inventory result to AIoT Controller.

[0043] ○ Delivers Commands from an AIoT controller to an AIoT Device.

[0044] ○ Delivers Command Responses received from an AIoT Device to an AIoT Controller.

[0045] In some example implementations, the AIoT controller may be a 3GPP core network entity and may support following functions:

[0046] ● Register Readers.

[0047] ● Authenticate and authorize AFs.

[0048] ● Based on requests from an AF:

[0049] ○ Verify whether an AF is entitled to issue a specific Inventory Request.

[0050] ○ Select Readers to fulfil Inventory or Command request by AFs.

[0051] ○ Forward Inventory request to Readers and deliver Inventory result to AF.

[0052] ○ Forward Command to Readers and Command Responses to AF.

[0053] ● Optionally collect usage data per AF, e.g. for charging purposes.

[0054] ● Store last known Reader information for AIoT Devices.

[0055] The AF may support following functions:

[0056] ● Authenticate towards the AIoT Controller.

[0057] ● Send Inventory and Command Requests.

[0058] ● Receive Inventory Responses and Command Responses.

[0059] One typical AIoT use case is inventory in the warehouse, where the environment is closed and controllable by the warehouse owner (as the 3rd party / AF) and the AIoT network operator. In addition to the architectures in FIGs. 4A-4B, the architecture may be enhanced with a core network function, AIoT device Management, which can manage the AIoT device including the indication whether this AIoT device can be operated with or without security and privacy requirements on the device and the related Reader (s) . The AIoT device management may manage AIoT devices, for example, by storing reader (s) corresponding to each AIoT device. An example AIoT system architecture with the AIoT device management entity is illustrated in FIG. 4C.

[0060] In this disclosure, a new entity, AIoT device Security Management (ADSM) entity is proposed. FIG. 4D shows an example AIoT system with an ADSM deployed. In this example, the ADSM is co-located with the AIoT device Management entity. In some other example implementations, the ADSM may be deployed in a stand-alone manner.

[0061] The ADSM may manage the subscription information and security information of A-IoT devices. It can be co-located with the AIoT device Management, UDM, or another entity, and provides security-related capabilities. In this disclosure, examples are given using a co-located ADSM, but the underlying principles apply to a stand-alone ADSM as well.

[0062] Specifically, the ADSM may provide AIoT device security management, which may include at least one of:

[0063] 1. Stores an initial key, namely Kaiot, for each A-IoT device. This key is used to ensure secure communication between the AIoT device and the network. Note that the same initial AIoT device key is provisioned at both the ADSM and the AIoT device itself.

[0064] 2. Stores an initial value of a counter associated with an A-IoT device. The counter is used to calculate a Message Authentication Code (MAC) value for verifying the authenticity of messages between the A-IoT device and the network. The range of the counter value may be from zero to a maximum counter value (e.g., 31) . The minimum and / or maximum counter value may be predefined and / or configurable. The initial value of the counter may be any value in the counter value range (e.g., 0 to 31) . The initial value may be configured or pre-allocated for the AIoT device.

[0065] 3. Maintains the counter value. For example, the counter will start from its initial value. Each time the counter is used for calculating a MAC value, it will be refreshed (e.g., incremented by, for example, one) . Note that the counter maintained by the AIoT device (device side counter) and the counter maintained by the network (e.g., ADSM) are synchronized with each other. The device side counter and the network side counter are peer or counterpart to each other. In this disclosure, the counter maintained by the AIoT device may be referred as a device side counter, and the counter maintained by the network (e.g., ADSM, other core network elements, or reader) may be referred as a network side counter.

[0066] In this disclosure, for security reason, the counter value is not transmitted in the air interface between the AIoT device and the network. A counter reset (or counter re-start) flag / indicator may be used in the AIoT system. For example, when the counter value reaches the initial value (e.g., as the counter value is refreshed) , the network side (e.g., ADSM) may use this indicator to instruct the AIoT device that network side has reset / restarted the counter. By using the counter reset indicator, the real counter is not transmitted in the air interface. Additionally, the counter reset indicator may serve as an error correction mechanism in the AIoT system –if there is a counter mismatch between the  AIoT device and the network (e.g., ADSM) , the AIoT device will perform a counter reset upon receiving the counter reset indicator, so as to re-synchronize the counter with the network side. Likewise, the AIoT device may also use a device side counter reset indicator, to notify the network side that the device side counter has been reset. Therefore, the network side counter reset indicator and the device side counter reset indictor may be used to facilitate counter synchronization.

[0067] In some example implementations, when a counter reset indicator is received, the reception party (e.g., AIoT device, or core network entity such as AIoT controller, ADSM) may simply resetting its own counter. In some example implementations, the receiving party will further check whether the device side counter is out of synchronization with the network side counter, Only if these two counters mismatch, a counter reset will happen.

[0068] AIoT Device ID

[0069] An AIoT device ID may be formed by grouping multiple 3GPP defined identifiers, including: a home network identifier, an owner identifier, and an instance identifier.

[0070] The home network identifier identified the home network of the AIoT device.

[0071] The owner identifier identified the owner (e.g., a vendor or supplier of merchandises) of the AIoT device and has to be unique within the Mobile Network Operator (MNO) identified by the Home Network Identifier.

[0072] The Instance Identifier identified the AIoT device instance in the scope of (home network identifier + owner identifier) . The Instance Identifier has to be unique within the Owner Identifier (which in turn is unique within a Home Network Identifier) . The means that the AIoT Device ID is unique globally.

[0073] In some example implementations, a third party defined identifier (non 3GPP) may be added to the AIoT device ID. The third party-defined identifier is controlled by a third party and can be used by the third party to group AIoT Devices together.

[0074] To identify or target an AIoT device, a full AIoT device ID may be used (i.e., the ID with home network identifier, the owner identifier, and the instance identifier) . Alternatively, a wild card format AIoT device ID may be used, to identify a group of AIoT devices that fall into this wild card AIoT device ID. For example, when only a portion of the full ID is specified (e.g., home network identifier + owner identifier) , all AIoT devices under the same owner identified by the owner identifier may be targeted.

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

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

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

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

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

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

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

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

[0083] In this disclosure, various embodiments are described, in order to protect the communication between AIoT device and the network. The network may include at least one of: a reader, an AIoT controller, an AIoT device management, an AIoT device security management, or an Application Function (AF) . For example, a message may be protected by a Message Authentication Code (MAC) , which may be calculated based on a random number, or a counter (value of the counter) .

[0084] Embodiment 1: A-IoT Controller Calculates MAC Based on Random Number

[0085] In this embodiment, AIoT device and AIoT device security management (ADSM) both store a same copy of the initial key, Kaiot, for the AIoT device. That is, the initial key Kaiot is synchronized between the AIoT device and ADSM. The AIoT device also stores its own Device ID, and the A-IoT device security management stores the mapping relationship between the Device ID of the AIoT device and a reader ID of the reader associated with (or serving) the AIoT device.

[0086] An exemplary method according to this embodiment is illustrated in FIG. 7 and may include a portion or all of the following steps.

[0087] Step 1: When initiating or triggering a service to AIoT device (s) , the AF may send a service message (e.g., inventory request, or command) to the A-IoT controller, the service message may carry at least one of: a Reader ID, or a Device ID of the AIoT device. The Reader ID designates the target reader serving the AIoT device, while the device ID specifies the AIoT device for which the service message (inventory request or the command) is intended.

[0088] In some example implementations, multiple Reader IDs may be included in the service message, in case multiple readers are involved.

[0089] Similarly, in some example implementations, multiple Device IDs may be included. Multiple devices may be specified via: a list of device IDs; a wildcard device ID which matches or indicates multiple AIoT devices.

[0090] Steps 2-3 below may be optional.

[0091] Step 2: A-IoT controller sends an inquiry, such as a device information request to the ADSM, which may carry the device ID received in step 1. If multiple Device IDs (e.g., a device ID list) are received in step 1, the A-IoT controller may repeat this step for each individual device ID by sending multiple inquiry message, or the A-IoT controller may send the Device ID list, or the device ID in wildcard format to the ADSM in a single message.

[0092] Step 3: The ADSM may respond with device information to the A-IoT controller, the device information may carry at least one of: the reader ID of the reader associated with, or serving the AIoT device; or the key for the AIoT device, Kaiot.

[0093] If Multiple Device IDs (e.g., device ID list or wildcard device ID) are received in step 2, this message may include device information corresponding to all the AIoT devices. Device information for multiple devices may be sent in multiple messages, or may be combined in one message.

[0094] In some example implementations, the Kaiot may be shared by AIoT devices (indicated by the device ID in step 1) . In some example implementations, each AIoT device  may have its dedicated Kaiot.

[0095] Step 4: The A-IoT controller may generate a network side random number RANDn, and calculate a network side Message Authentication Code, MACn based on the Kaiot and RANDn. For example, MACn = HASH (device ID, reader ID, RANDn, Kaiot) . The hash function may include, for example, a Secure Hash Algorithm 256-bit (SHA 256) , and other secure hash algorithms. In this example, the message may be a concatenation of device ID, reader ID, and RANDn, and Kaiot is the hash key.

[0096] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the MAC. Alternatively, a partial AIoT device ID may be used in the hash function. For example, a home network identifier, an owner identifier, or an instance identifier may be used alone or in combinations.

[0097] Step 5: The A-IoT controller may send a service message (e.g., inventory request, or command) to the reader (s) base on reader ID (s) (e.g., reader ID received in step 3) . This service message may carry at least one of: Device ID of the AIoT device; RANDn; or MACn.

[0098] Note that if multiple readers are required to fulfill the initial service message in step 1, the AIoT controller may send separate service message to each involved reader.

[0099] For the sake of simplicity, the description below focuses on a single reader, but the same principles apply to other involved readers.

[0100] Step 6: The reader may forward the service message (e.g., inventory request, or command) to AIoT device. The service message may carry at least one of: Device ID of the AIoT device; RANDn; or MACn.

[0101] Step 7: The AIoT device verifies the validity of MACn. Specifically, the A-IoT device may calculate a local MACn', for example, MACn'= HASH (device ID, reader ID, RANDn, Kaiot) . In some example implementations, the device ID and RANDn may be the  parameters sent by the reader in step 6. In some example implementations, the AIoT device may use its stored device ID. The reader ID may be indicated explicitly or implicitly by the service message received in step 6.

[0102] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the local MACn'. Alternatively, if a partial AIoT device ID is received in step 6, then the partial AIoT device ID may be used in the hash function. For example, if the AIoT device is identified by a partial ID formed by its home network identifier and its owner identifier (which are received in step 6) , then the hash function may use this partial AIoT device ID.

[0103] If MACn (copy of MAC received from the reader) and MACn' (local copy calculated by AIoT device) are the same, then the MAC verification succeeds. Otherwise, the verification fails, and the AIoT device may simply drop the message received in step 6 and stop.

[0104] If the MAC validation is successful, the A-IoT device may optionally generate a RANDu (user side, or device side random number) and calculate a MACu (user side, or device side MAC) based on it. For example, MACu = HASH (device ID, reader ID, RANDu, Kaiot) , where Kaiot is the initial key for the AIoT device that is locally stored on the A-IoT device.

[0105] In this disclosure, whenever a MAC validation fails, the operation may be stopped, and the incoming message may be dropped by the receiving party,

[0106] Step 8: The A-IoT device may send a service response message to the reader, as a response to the service message in step 6. The service response message may include an inventory response message, or a command response message. The service response message may carry at least one of: RANDu; MACu; or deviceID of the AIoT device (e.g., at instance level –with all 3GPP identifier included, which uniquely identify the AIoT device; or at another  level) .

[0107] Step 9: The Reader may forward the service response message (e.g., inventory response message, or a command response message) to the A-IoT controller. The service response message may carry at least one of: RANDu; MACu; device ID of the AIoT device; or reader ID.

[0108] Step 10: If MACu is carried in the service response message in step 9, the A-IoT controller calculates the its local copy of MACu', in a similar way as the A-IoT device does in step 7, and verifies the validity of MACu' (i.e., whether MACu'equals to MACu received in step 9) . If the verification is successful, the service response message is valid.

[0109] Step 11: A-IoT controller stores the device ID of the AIoT device, and the reader ID. Note that if there are multiple readers involved, one or more service response messages may be received by the AIoT controller. Based on the service response message (s) , the AIoT control may establish a record which stores all the AIoT devices which are covered by the service response message (s) . The record may further store a reader ID corresponding to each AIoT device. The AIoT controller may then send a service response message (e.g., as a response to the service message in step 1) to the AF. The service response message may carry the AIoT device ID (s) and its corresponding reader (e.g., via a reader ID) . Note that one or more service response message (s) may be used.

[0110] Embodiment 2: A-IoT Controller Calculates MAC Based on Counter

[0111] In this embodiment, AIoT device and AIoT device security management (ADSM) both store a same copy of the initial key, Kaiot, for the AIoT device. That is, the initial key Kaiot is synchronized between the AIoT device and ADSM. The AIoT device also stores its own Device ID, and the A-IoT device security management stores the mapping relationship between the Device ID of the AIoT device and a reader ID of the reader associated with (or serving) the AIoT device.

[0112] The AIoT device and the ADSM may both store a same initial value for a  respective counter (device side counter and network side counter) . As describe earlier, the counter will start from its initial value. Each time the counter is used for calculating a MAC value, it will be refreshed (e.g., incremented by, for example, one) . Note that the counter maintained by the AIoT device (device side counter) and the counter maintained by the network (e.g., ADSM) are synchronized with each other. The device side counter and the network side counter are peer or counterpart to each other.

[0113] An exemplary method according to this embodiment are illustrated in FIG. 8 and may include a portion or all of the following steps.

[0114] Step 1: When initiating a service to AIoT device (s) , the AF may send a service message (e.g., inventory request, or command) to the A-IoT controller, the service message may include at least one of: a Reader ID, or a Device ID of the AIoT device. The Reader ID designates the target reader, while the device ID specifies the AIoT device for which the inventory request or the command is intended.

[0115] In some example implementations, multiple Reader IDs may be included in the service message, in case multiple readers are involved.

[0116] Similarly, in some example implementations, multiple Device IDs may be included. Multiple devices may be specified via: a list of device IDs; a wildcard device ID which matches or indicates multiple AIoT devices.

[0117] Steps 2-3 below may be optional.

[0118] Step 2: A-IoT controller sends an inquiry, such as a device information request to the ADSM, which may carry the device ID received in step 1. If multiple Device IDs (e.g., a device ID list) are received in step 1, the A-IoT controller may repeat this step for each individual device ID by sending multiple inquiry message, or the A-IoT controller may send the Device ID list, or the device ID in wildcard format to the ADSM in a single message.

[0119] Step 3: The ADSM may respond with device information to the A-IoT controller, the device  information may carry at least one of: the reader ID of the reader associated with, or serving the AIoT device; the key for the AIoT device, Kaiot; or the network side counter (value of this counter) . Note that when the value of the network side counter is equal to its initial value (e.g., initial value in the counter value range, which may be predefined and is configurable) , a network side counter reset indicator is also carried in the message. That is, the network side counter reset indicator indicates that the network side counter is reset to or re-started from its initial value.

[0120] If Multiple Device IDs (e.g., device ID list or wildcard device ID) are received in step 2, this message may include device information corresponding to all the AIoT devices. Device information for multiple devices may be sent in multiple messages, or may be combined in one message.

[0121] In some example implementations, the Kaiot may be shared by AIoT devices (indicated by the device ID in step 1) . For example, all AIoT devices belonging to a same owner may share a same key. In some example implementations, each AIoT device may have its dedicated Kaiot.

[0122] Step 4: The A-IoT controller may calculate a network side Message Authentication Code, MACn based on the Kaiot and network side counter value. For example, MACn = HASH (device ID, reader ID, counter, Kaiot) . The hash function may include, for example, a Secure Hash Algorithm 256-bit (SHA 256) , and other secure hash algorithms. In this example, the message may be a concatenation of device ID, reader ID, and counter (i.e., value of network side counter) , and Kaiot is the hash key.

[0123] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the MAC. Alternatively, a partial AIoT device ID may be used in the hash function. For example, a home network identifier, an owner identifier, or an instance identifier may be used alone or in combinations.

[0124] Step 5: The A-IoT controller may send a service message (e.g., inventory request, or command) to the reader (s) base on reader ID (s) (e.g., reader ID received in step 3) . This service message may include at least one of: Device ID of the AIoT device; or MACn. If a network side counter reset indicator is received in step 3, then this indicator may also be carried in the service message to the reader.

[0125] Note that if multiple readers are required to fulfill the initial service message in step 1, the AIoT controller may send separate service message to each involved reader.

[0126] For the sake of simplicity, the description below focuses on a single reader, but the same principles apply to other involved readers.

[0127] Step 6: The reader may forward the service message (e.g., inventory request, or command) to A-IoT device. The service message may carry at least one of: Device ID of the AIoT device; MACn. If the network side counter reset indicator is received in step 5, then it may also be carried by the service message.

[0128] Step 7: The A-IoT device verifies the validity of MACn. That is, the A-IoT device may calculate a local MACn', for example, MACn'= HASH (device ID, reader ID, counter, Kaiot) . The device ID may be the parameter sent by the reader in step 6. Note that after the MACn'calculation, the value of the device side counter is refreshed (e.g., incremented) .

[0129] Note that if the network side counter reset indicator is carried in the service message in step 6, it indicates that the network side counter is reset to its initial value. This give the AIoT device a chance to make error correction in case the device side counter is out of synchronization with the network side counter. For example, if the value of the device side counter is not initial value, the reception of the network side counter reset indicator will trigger the AIoT device to reset the device side counter. In this case, the MACn'described above will be calculated using the initial counter value.

[0130] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function  for calculating the local MACn'. Alternatively, if a partial AIoT device ID is received in step 6, then the partial AIoT device ID may be used in the hash function. For example, if the AIoT device is identified by a partial ID formed by its home network identifier and its owner identifier (which are received in step 6) , then the hash function may use this partial AIoT device ID.

[0131] If MACn (the MAC received from the reader) and MACn' (local copy calculated by AIoT device) are the same, then the MAC verification succeeds. Otherwise, the verification fails, and the AIoT device may simply drop the message received in step 6 and stop.

[0132] If the MAC validation is successful, the A-IoT device may optionally generate a user side MAC, MACu, based on a refreshed device side counter (e.g., increment by one after calculating the MACn') . For example, MACu = HASH (device ID, reader ID, refreshed counter, Kaiot) , where Kaiot is the initial key for the AIoT device that is locally stored on the A-IoT device. Note when using a counter in hash operation, it means using the value of the counter.

[0133] Step 8: The A-IoT device may send a service response message to the reader, as a response to the service message in step 6. The service response message may include an inventory response message, or a command response message. The service response message may carry at least one of: MACu; or device ID of the AIoT device (e.g., at instance level –with all 3GPP identifier included, which uniquely identify the AIoT device; or at another level) .

[0134] Note that if the refreshed device side counter (either after calculating MACn', if MACu is not calculated; or after calculating MACu if MACus is calculated) is equal to its initial value, then the service response message may carry a device side counter reset indicator.

[0135] Step 9: The Reader may forward the service response message (e.g., inventory response message, or a command response message) to the A-IoT controller. The service response  message may carry at least one of: MACu; device ID of the AIoT device; or reader ID. If the device side counter reset indicator is received in step 8, then the service response message may forward this indicator as well.

[0136] Step 10: If MACu is carried in the service response message in step 9, the A-IoT controller calculates the its local copy of MACu', in a similar way as the A-IoT device does in step 7, and verifies the validity of MACu' (i.e., whether MACu'equals to MACu received in step 9) . If the verification is successful, the service response message is determined as valid.

[0137] Note that before calculating the MACu', the reader needs to first increment its local copy of the network side counter.

[0138] Step 11: A-IoT controller stores the device ID of the AIoT device, and the reader ID. Note that if there are multiple readers involved, one or more service response messages may be received by the AIoT controller. Based on the service response message (s) , the AIoT control may establish a record which store all the AIoT devices which are covered by the service response message (s) . The record may further store a reader ID corresponding to each AIoT device. The AIoT controller may then send a service response message (e.g., as a response to the service message in step 1) to the AF. The service response message may carry the AIoT device ID (s) and its corresponding reader (e.g., via a reader ID) . Note that one or more service response message (s) may be used.

[0139] Step 12: The AIoT controller may send a message (e.g., counter notification message) to the ADSM, carrying its current view of the network side counter value. For example, this may be due to that a device side counter reset, or the AIoT device sends a MACu in its response message to the reader.

[0140] Embodiment 3: Reader Calculates MAC Based on Random Number

[0141] In this embodiment, AIoT device and AIoT device security management (ADSM) both store a same copy of the initial key, Kaiot, for the AIoT device. That is, the initial key Kaiot is synchronized between the AIoT device and ADSM. The AIoT device also stores  its own Device ID, and the A-IoT device security management stores the mapping relationship between the Device ID of the AIoT device and a reader ID of the reader associated with (or serving) the AIoT device.

[0142] In this embodiment, the network side MAC is calculated by the reader.

[0143] An exemplary method according to this embodiment is illustrated in FIG. 9 and may include a portion or all of the following steps.

[0144] Step 1: When initiating a service to AIoT device (s) , the AF may send a service message (e.g., inventory request, or command) to the A-IoT controller, the service message may carry at least one of: a Reader ID, or a Device ID of the AIoT device. The Reader ID designates the target reader, while the device ID specifies the AIoT device for which the inventory request or the command is intended.

[0145] In some example implementations, multiple Reader IDs may be included in the service message, in case multiple readers are involved.

[0146] Similarly, in some example implementations, multiple Device IDs may be included. Multiple devices may be specified via: a list of device IDs; a wildcard device ID which matches or indicates multiple AIoT devices.

[0147] Step 2: A-IoT controller sends an inquiry, such as a device information request to the ADSM, which may carry the device ID received in step 1. If multiple Device IDs (e.g., a device ID list) are received in step 1, the A-IoT controller may repeat this step for each individual device ID by sending multiple inquiry message, or the A-IoT controller may send the Device ID list, or the device ID in wildcard format to the ADSM in a single message.

[0148] Step 3: The ADSM may respond with device information to the A-IoT controller, the device information may carry at least one of: the reader ID of the reader associated with, or serving the AIoT device; or the key for the AIoT device, Kaiot.

[0149] If Multiple Device IDs (e.g., device ID list or wildcard device ID) are received in  step 2, this message may include device information corresponding to all the AIoT devices. Device information for multiple devices may be sent in multiple messages, or may be combined in one message.

[0150] In some example implementations, the Kaiot may be shared by AIoT devices (indicated by the device ID in step 1) . In some example implementations, each AIoT device may have its dedicated Kaiot.

[0151] Step 4: The A-IoT controller may send a service message (e.g., inventory request, or command) to the reader (s) base on reader ID (s) (e.g., reader ID received in step 3) . This service message may include at least one of: Device ID of the AIoT device; or the key for the AIoT device, Kaiot.

[0152] Note that if multiple readers are required to fulfill the initial service message in step 1, the AIoT controller may send separate service message to each involved reader.

[0153] For the sake of simplicity, the description below focuses on a single reader, but the same principles apply to other involved readers.

[0154] Step 5: The reader may generate a network side random number RANDn, and calculate a network side Message Authentication Code, MACn based on the Kaiot and RANDn. For example, MACn = HASH (device ID, reader ID, RANDn, Kaiot) . The hash function may include, for example, a Secure Hash Algorithm 256-bit (SHA 256) , and other secure hash algorithms. In this example, the message may be a concatenation of device ID, reader ID, and RANDn, and Kaiot is the hash key. The reader ID is the identifier of the reader.

[0155] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the MAC. Alternatively, a partial AIoT device ID may be used in the hash function. For example, a home network identifier, an owner identifier, or an instance identifier may be used alone or in combinations.

[0156] Step 6: The reader may forward the service message (e.g., inventory request, or command) to A-IoT device. The service message may carry at least one of: Device ID of the AIoT device; RANDn; or MACn.

[0157] Step 7: The A-IoT device verifies the validity of MACn. That is, the A-IoT device may calculate a local MACn', for example, MACn'= HASH (device ID, reader ID, RANDn, Kaiot) . The device ID and RANDn may be the parameters sent by the reader in step 6. The reader ID may be indicated explicitly or implicitly by the service message received in step 6.

[0158] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the local MACn'. Alternatively, if a partial AIoT device ID is received in step 6, then the partial AIoT device ID may be used in the hash function. For example, if the AIoT device is identified by a partial ID formed by its home network identifier and its owner identifier (which are received in step 6) , then the hash function may use this partial AIoT device ID.

[0159] If MACn (copy of MAC received from the reader) and MACn' (local copy calculated by AIoT device) are the same, then the MAC verification succeeds. Otherwise, the verification fails, and the AIoT device may simply drop the message received in step 6 and stop.

[0160] If the MAC validation is successful, the A-IoT device may optionally generate a RANDu (user side, or device side random number) and calculate a MACu (user side, or device side MAC) based on it. For example, MACu = HASH (device ID, reader ID, RANDu, Kaiot) , where Kaiot is the initial key for the AIoT device that is locally stored on the A-IoT device.

[0161] Step 8: The A-IoT device may send a service response message to the reader, as a response to the service message in step 6. The service response message may include an inventory  response message, or a command response message. The service response message may carry at least one of: RANDu; MACu; or deviceID of the AIoT device (e.g., at instance level –with all 3GPP identifier included, which uniquely identify the AIoT device; or at another level) .

[0162] Step 9: If MACu is carried in the service response message in step 8, the reader calculates the its local copy of MACu', in a similar way as the A-IoT device does in step 7, and verifies the validity of MACu' (i.e., whether MACu'equals to MACu received in step 9) . If the verification is successful, the service response message is valid.

[0163] Step 10: The reader may forward the service response message (e.g., inventory response message, or a command response message) to the A-IoT controller. The service response message may carry at least one of: device ID of the AIoT device; or reader ID.

[0164] Step 11: A-IoT controller stores the device ID of the AIoT device, and the reader ID. Note that if there are multiple readers involved, one or more service response messages may be received by the AIoT controller. Based on the service response message (s) , the AIoT control may establish a record which store all the AIoT devices which are covered by the service response message (s) . The record may further store a reader ID corresponding to each AIoT device. The AIoT controller may then send a service response message (e.g., as a response to the service message in step 1) to the AF. The service response message may carry the AIoT device ID (s) and its corresponding reader (e.g., via a reader ID) . Note that one or more service response message (s) may be used.

[0165] Embodiment 4: Reader Calculates MAC Based on Counter

[0166] In this embodiment, AIoT device and AIoT device security management (ADSM) both store a same copy of the initial key, Kaiot, for the AIoT device. That is, the initial key Kaiot is synchronized between the AIoT device and ADSM. The AIoT device also stores its own Device ID, and the A-IoT device security management stores the mapping relationship between the Device ID of the AIoT device and a reader ID of the reader  associated with (or serving) the AIoT device.

[0167] In this embodiment, the network side MAC is calculated by the reader.

[0168] The AIoT device and the ADSM may both store a same initial value for a respective counter (device side counter and network side counter) . As describe earlier, the counter will start from its initial value. Each time the counter is used for calculating a MAC value, it will be refreshed (e.g., incremented by, for example, one) . Note that the counter maintained by the AIoT device (device side counter) and the counter maintained by the network (e.g., ADSM) are synchronized with each other. The device side counter and the network side counter are peer or counterpart to each other.

[0169] An exemplary method according to this embodiment are illustrated in FIG. 10 and may include a portion or all of the following steps.

[0170] Step 1: When initiating a service to AIoT device (s) , the AF may send a service message (e.g., inventory request, or command) to the A-IoT controller, the service message may include at least one of: a Reader ID, or a Device ID of the AIoT device. The Reader ID designates the target reader, while the device ID specifies the AIoT device for which the inventory request or the command is intended.

[0171] In some example implementations, multiple Reader IDs may be included in the service message, in case multiple readers are involved.

[0172] Similarly, in some example implementations, multiple Device IDs may be included. Multiple devices may be specified via: a list of device IDs; a wildcard device ID which matches or indicates multiple AIoT devices.

[0173] Step 2: A-IoT controller sends an inquiry, such as a device information request to the ADSM, which may carry the device ID received in step 1. If multiple Device IDs (e.g., a device ID list) are received in step 1, the A-IoT controller may repeat this step for each individual device ID by sending multiple inquiry message, or the A-IoT controller may send the Device  ID list, or the device ID in wildcard format to the ADSM in a single message.

[0174] Step 3: The ADSM may respond with device information to the A-IoT controller, the device information may carry at least one of: the reader ID of the reader associated with, or serving the AIoT device; the key for the AIoT device, Kaiot; or the network side counter (value of this counter) . Note that when the value of the network side counter is equal to its initial value (e.g., initial value in the counter value range, which may be predefined and is configurable) , a network side counter reset indicator is also carried in the message. That is, the network side counter reset indicator indicates that the network side counter is reset or re-started from its initial value.

[0175] If Multiple Device IDs (e.g., device ID list or wildcard device ID) are received in step 2, this message may include device information corresponding to all the AIoT devices. Device information for multiple devices may be sent in multiple messages, or may be combined in one message.

[0176] In some example implementations, the Kaiot may be shared by AIoT devices (indicated by the device ID in step 1) . For example, all AIoT devices belonging to a same owner may share a same key. In some example implementations, each AIoT device may have its dedicated Kaiot.

[0177] Step 4: The A-IoT controller may send a service message (e.g., inventory request, or command) to the reader (s) base on reader ID (s) (e.g., reader ID received in step 3) . This service message may include at least one of: Device ID of the AIoT device; the key for the AIoT device, Kaiot; or the network side counter (value of this counter) . If a network side counter reset indicator is received in step 3, then this indicator may also be carried in the service message to the reader.

[0178] Note that if multiple readers are required to fulfill the initial service message in step 1, the AIoT controller may send separate service message to each involved reader.

[0179] For the sake of simplicity, the description below focuses on a single reader, but  the same principles apply to other involved readers.

[0180] Step 5: The reader may calculate a network side Message Authentication Code, MACn based on the Kaiot and network side counter value. For example, MACn = HASH (device ID, reader ID, counter, Kaiot) . The hash function may include, for example, a Secure Hash Algorithm 256-bit (SHA 256) , and other secure hash algorithms. In this example, the message may be a concatenation of device ID, reader ID, and counter (i.e., value of network side counter) , and Kaiot is the hash key.

[0181] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the MAC. Alternatively, a partial AIoT device ID may be used in the hash function. For example, a home network identifier, an owner identifier, or an instance identifier may be used alone or in combinations.

[0182] Step 6: The reader may forward the service message (e.g., inventory request, or command) to A-IoT device. The service message may carry at least one of: Device ID of the AIoT device; or MACn. If the network side counter reset indicator is received in step 5, then it may be carried by the service message.

[0183] Step 7: The A-IoT device verifies the validity of MACn. That is, the A-IoT device may calculate a local MACn', for example, MACn'= HASH (device ID, reader ID, counter, Kaiot) . The device ID may be the parameter sent by the reader in step 6. Note that after the MACn'calculation, the value of the device side counter is refreshed (e.g., incremented) .

[0184] Note that if the network side counter reset indicator is carried in the service message in step 6, it indicates that the network side counter is reset to its initial value. This give the AIoT device a chance to make error correction in case the device side counter is out of synchronization with the network side counter. For example, if the value of the device side counter is not initial value, the reception of the network side counter reset indicator will trigger the AIoT device to reset the device side counter. In this case, the MACn'described  above will be calculated using the initial counter value.

[0185] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the local MACn'. Alternatively, if a partial AIoT device ID is received in step 6, then the partial AIoT device ID may be used in the hash function. For example, if the AIoT device is identified by a partial ID formed by its home network identifier and its owner identifier (which are received in step 6) , then the hash function may use this partial AIoT device ID.

[0186] If MACn (copy of MAC received from the reader) and MACn' (local copy calculated by AIoT device) are the same, then the MAC verification succeeds. Otherwise, the verification fails, and the AIoT device may simply drop the message received in step 6 and stop.

[0187] If the MAC validation is successful, the A-IoT device may optionally generate user side MAC, MACu, based on a refreshed device side counter (e.g., increment by one after calculating the MACn') . For example, MACu = HASH (device ID, reader ID, refreshed counter, Kaiot) , where Kaiot is the initial key for the AIoT device that is locally stored on the A-IoT device. Note when using a counter in hash operation, it means using the value of the counter.

[0188] Step 8: The A-IoT device may send a service response message to the reader, as a response to the service message in step 6. The service response message may include an inventory response message, or a command response message. The service response message may carry at least one of: MACu; or device ID of the AIoT device (e.g., at instance level –with all 3GPP identifier included, which uniquely identify the AIoT device; or at another level) .

[0189] Note that if the refreshed device side counter (either after calculating MACn', if MACu is not calculated; or after calculating MACu if MACu is calculated) is equal to its initial value, then the service response message may carry a device side counter reset  indicator.

[0190] Step 9: If MACu is carried in the service response message in step 8, the reader calculates the its local copy of MACu', in a similar way as the A-IoT device does in step 7, and verifies the validity of MACu' (i.e., whether MACu'equals to MACu received in step 9) . If the verification is successful, the service response message is determined as valid.

[0191] Note that before calculating the MACu', the reader needs to first increment its local copy of the network side counter.

[0192] Note that if the device side counter reset indicator is carried in the service response message in step 8, it indicates that the device side counter (maintained by AIoT device) is reset to its initial value. This give the reader a chance to make error correction in case the network side counter is out of synchronization with the device side counter. For example, if the value of the network side counter is not initial value, the reception of the device side counter reset indicator will trigger the reader to reset the network side counter. In this case, the MACn'described above will be calculated using the initial counter value.

[0193] Step 10: The Reader may forward the service response message (e.g., inventory response message, or a command response message) to the A-IoT controller. The service response message may carry at least one of: MACu; device ID of the AIoT device; or reader ID. The service response message may also carry the latest value for the network side counter.

[0194] Step 11: A-IoT controller stores the device ID of the AIoT device, and the reader ID. Note that if there are multiple readers involved, one or more service response messages may be received by the AIoT controller. Based on the service response message (s) , the AIoT control may establish a record which store all the AIoT devices which are covered by the service response message (s) . The record may further store a reader ID corresponding to each AIoT device. The AIoT controller may then send a service response message (e.g., as a response to the service message in step 1) to the AF. The service response message may carry the AIoT device ID (s) and its corresponding reader (e.g., via a reader ID) . Note that  one or more service response message (s) may be used.

[0195] The AIoT controller may update its local view of the network side counter value, if a network side counter value is received in step 10.

[0196] Step 12: The AIoT controller may send a message (e.g., counter notification message) to the ADSM, carrying its current view of the network side counter value. For example, this may be due to that a device side counter reset, or the AIoT device sends a MACu in its response message to the reader.

[0197] Embodiment 5: Reader Requests AIoT Device Key from ADSM and Calculates MAC Based on Random Number

[0198] In this embodiment, AIoT device and AIoT device security management (ADSM) both store a copy of the initial key, Kaiot, for the AIoT device. That is, the initial key Kaiot is synchronized between the AIoT device and ADSM.

[0199] In this embodiment, the reader requests the key for AIoT device from, for example, the ADSM, and calculates the network side MAC.

[0200] An exemplary method according to this embodiment is illustrated in FIG. 11 and may include a portion or all of the following steps.

[0201] Step 1: When initiating a service to AIoT device (s) , the AF may send a service message (e.g., inventory request, or command) to the A-IoT controller, the service message may carry at least one of: a Reader ID, or a Device ID of the AIoT device. The Reader ID designates the target reader, while the device ID specifies the AIoT device for which the inventory request or the command is intended.

[0202] In some example implementations, multiple Reader IDs may be included in the service message, in case multiple readers are involved.

[0203] Similarly, in some example implementations, multiple Device IDs may be  included. Multiple devices may be specified via: a list of device IDs; a wildcard device ID which matches or indicates multiple AIoT devices.

[0204] Step 2: A-IoT controller sends an inquiry, such as a device information request to the ADSM, which may carry the device ID received in step 1. If multiple Device IDs (e.g., a device ID list) are received in step 1, the A-IoT controller may repeat this step for each individual device ID by sending multiple inquiry message, or the A-IoT controller may send the Device ID list, or the device ID in wildcard format to the ADSM in a single message.

[0205] Step 3: The ADSM may respond with device information to the A-IoT controller, the device information may carry the reader ID of the reader associated with, or serving the AIoT device.

[0206] If Multiple Device IDs (e.g., device ID list or wildcard device ID) are received in step 2, this message may include device information corresponding to all the AIoT devices. Device information for multiple devices may be sent in multiple messages, or may be combined in one message.

[0207] Step 4: The A-IoT controller may send a service message (e.g., inventory request, or command) to the reader (s) base on reader ID (s) (e.g., reader ID received in step 3) . This service message may include Device ID of the AIoT device;

[0208] Note that if multiple readers are required to fulfill the initial service message in step 1, the AIoT controller may send separate service message to each involved reader.

[0209] For the sake of simplicity, the description below focuses on a single reader, but the same principles apply to other involved readers.

[0210] Step 5: The reader may request key for the AIoT device, Kaiot, from the ADSM. The key request message may include the device ID of the AIoT device received in step 4.

[0211] Step 6: The ADSM may send a response to the reader, which may include Kaiot of the AIoT device.

[0212] In some example implementations, the Kaiot may be shared by AIoT devices (indicated by the device ID in step 1) . In some example implementations, each AIoT device may have its dedicated Kaiot.

[0213] Step 7: The reader may generate a network side random number RANDn, and calculate a network side Message Authentication Code, MACn based on the Kaiot and RANDn. For example, MACn = HASH (device ID, reader ID, RANDn, Kaiot) . The hash function may include, for example, a Secure Hash Algorithm 256-bit (SHA 256) , and other secure hash algorithms. In this example, the message may be a concatenation of device ID, reader ID, and RANDn, and Kaiot is the hash key. The reader ID is the identifier of the reader.

[0214] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the MAC. Alternatively, a partial AIoT device ID may be used in the hash function. For example, a home network identifier, an owner identifier, or an instance identifier may be used alone or in combinations.

[0215] Step 8: The reader may forward the service message (e.g., inventory request, or command) to A-IoT device. The service message may carry at least one of: Device ID of the AIoT device; RANDn; or MACn.

[0216] Step 9: The A-IoT device verifies the validity of MACn. That is, the A-IoT device may calculate a local MACn', for example, MACn'= HASH (device ID, reader ID, RANDn, Kaiot) . The device ID and RANDn may be the parameters sent by the reader in step 6. The reader ID may be indicated explicitly or implicitly by the service message received in step 6.

[0217] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the local MACn'. Alternatively, if a partial AIoT device ID is received in step 6, then the partial AIoT device ID may be used in the hash function. For example, if  the AIoT device is identified by a partial ID formed by its home network identifier and its owner identifier (which are received in step 6) , then the hash function may use this partial AIoT device ID.

[0218] If MACn (copy of MAC received from the reader) and MACn' (local copy calculated by AIoT device) are the same, then the MAC verification succeeds. Otherwise, the verification fails, and the AIoT device may simply drop the message received in step 6 and stop.

[0219] If the MAC validation is successful, the A-IoT device may optionally generate a RANDu (user side, or device side random number) and calculate a MACu (user side, or device side MAC) based on it. For example, MACu = HASH (device ID, reader ID, RANDu, Kaiot) , where Kaiot is the initial key for the AIoT device that is locally stored on the A-IoT device.

[0220] Step 10: The A-IoT device may send a service response message to the reader, as a response to the service message in step 6. The service response message may include an inventory response message, or a command response message. The service response message may carry at least one of: RANDu; MACu; or device ID of the AIoT device (e.g., at instance level –with all 3GPP identifier included, which uniquely identify the AIoT device; or at another level) .

[0221] Step 11: If MACu is carried in the service response message in step 8, the reader calculates the its local copy of MACu', in a similar way as the A-IoT device does in step 7, and verifies the validity of MACu' (i.e., whether MACu'equals to MACu received in step 9) . If the verification is successful, the service response message is valid.

[0222] Step 12: The reader may forward the service response message (e.g., inventory response message, or a command response message) to the A-IoT controller. The service response message may carry at least one of: device ID of the AIoT device; or reader ID.

[0223] Step 13: A-IoT controller stores the device ID of the AIoT device, and the reader ID. Note  that if there are multiple readers involved, one or more service response messages may be received by the AIoT controller. Based on the service response message (s) , the AIoT control may establish a record which store all the AIoT devices which are covered by the service response message (s) . The record may further store a reader ID corresponding to each AIoT device. The AIoT controller may then send a service response message (e.g., as a response to the service message in step 1) to the AF. The service response message may carry the AIoT device ID (s) and its corresponding reader (e.g., via a reader ID) . Note that one or more service response message (s) may be used.

[0224] Embodiment 6: Reader Requests AIoT Device Key from ADSM and Calculates MAC Based on Counter

[0225] In this embodiment, AIoT device and AIoT device security management (ADSM) both store a same copy of the initial key, Kaiot, for the AIoT device. That is, the initial key Kaiot is synchronized between the AIoT device and ADSM. The AIoT device also stores its own Device ID, and the A-IoT device security management stores the mapping relationship between the Device ID of the AIoT device and a reader ID of the reader associated with (or serving) the AIoT device.

[0226] In this embodiment, the reader requests the key for AIoT device from, for example, the ADSM, and calculates the network side MAC.

[0227] The AIoT device and the ADSM may both store a same initial value for a respective counter (device side counter and network side counter) . As describe earlier, the counter will start from its initial value. Each time the counter is used for calculating a MAC value, it will be refreshed (e.g., incremented by, for example, one) . Note that the counter maintained by the AIoT device (device side counter) and the counter maintained by the network (e.g., ADSM) are synchronized with each other. The device side counter and the network side counter are peer or counterpart to each other.

[0228] An exemplary method according to this embodiment are illustrated in FIG. 12 and  may include a portion or all of the following steps.

[0229] Step 1: When initiating a service to AIoT device (s) , the AF may send a service message (e.g., inventory request, or command) to the A-IoT controller, the service message may include at least one of: a Reader ID, or a Device ID of the AIoT device. The Reader ID designates the target reader, while the device ID specifies the AIoT device for which the inventory request or the command is intended.

[0230] In some example implementations, multiple Reader IDs may be included in the service message, in case multiple readers are involved.

[0231] Similarly, in some example implementations, multiple Device IDs may be included. Multiple devices may be specified via: a list of device IDs; a wildcard device ID which matches or indicates multiple AIoT devices.

[0232] Step 2: A-IoT controller sends an inquiry, such as a device information request to the ADSM, which may carry the device ID received in step 1. If multiple Device IDs (e.g., a device ID list) are received in step 1, the A-IoT controller may repeat this step for each individual device ID by sending multiple inquiry message, or the A-IoT controller may send the Device ID list, or the device ID in wildcard format to the ADSM in a single message.

[0233] Step 3: The ADSM may respond with device information to the A-IoT controller, the device information may carry the reader ID of the reader associated with, or serving the AIoT device. Note that when the value of the network side counter is equal to its initial value (e.g., initial value in the counter value range, which may be predefined and is configurable) , a network side counter reset indicator is also carried in the message. That is, the network side counter reset indicator indicates that the network side counter is reset or re-started from its initial value.

[0234] If Multiple Device IDs (e.g., device ID list or wildcard device ID) are received in step 2, this message may include device information corresponding to all the AIoT devices. Device information for multiple devices may be sent in multiple messages, or may be  combined in one message.

[0235] Step 4: The A-IoT controller may send a service message (e.g., inventory request, or command) to the reader (s) base on reader ID (s) (e.g., reader ID received in step 3) . This service message may include the device ID of the AIoT device.

[0236] Note that if multiple readers are required to fulfill the initial service message in step 1, the AIoT controller may send separate service message to each involved reader.

[0237] For the sake of simplicity, the description below focuses on a single reader, but the same principles apply to other involved readers.

[0238] Step 5: The reader may request key for the AIoT device, Kaiot, from the ADSM. The key request message may include the device ID of the AIoT device received in step 4.

[0239] Step 6: The ADSM may send a response to the reader, which may include at least one of: Kaiot of the AIoT device; or a value of the network side counter, which is used for calculating the network side MAC in following step.

[0240] In some example implementations, the Kaiot may be shared by AIoT devices (indicated by the device ID in step 1) . In some example implementations, each AIoT device may have its dedicated Kaiot.

[0241] Step 7: The reader may calculate a network side Message Authentication Code, MACn based on the Kaiot and network side counter value received in step 6. For example, MACn =HASH (device ID, reader ID, counter, Kaiot) . The hash function may include, for example, a Secure Hash Algorithm 256-bit (SHA 256) , and other secure hash algorithms. In this example, the message may be a concatenation of device ID, reader ID, and counter (i.e., value of network side counter) , and Kaiot is the hash key.

[0242] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the MAC. Alternatively, a partial AIoT device ID may be used in the hash  function. For example, a home network identifier, an owner identifier, or an instance identifier may be used alone or in combinations.

[0243] Step 8: The reader may forward the service message (e.g., inventory request, or command) to A-IoT device. The service message may carry at least one of: Device ID of the AIoT device; or MACn. If the network side counter reset indicator is received in step 5, then it may be carried by the service message.

[0244] Step 9: The A-IoT device verifies the validity of MACn. That is, the A-IoT device may calculate a local MACn', for example, MACn'= HASH (device ID, reader ID, counter, Kaiot) . The device ID may be the parameter sent by the reader in step 6. Note that after the MACn'calculation, the value of the device side counter is refreshed (e.g., incremented) .

[0245] Note that if the network side counter reset indicator is carried in the service message in step 6, it indicates that the network side counter is reset to its initial value. This give the AIoT device a chance to make error correction in case the device side counter is out of synchronization with the network side counter. For example, if the value of the device side counter is not initial value, the reception of the network side counter reset indicator will trigger the AIoT device to reset the device side counter. In this case, the MACn'described above will be calculated using the initial counter value.

[0246] In some example implementations, if a bulk device ID (e.g., list of AIoT device ID, or wildcard device ID) is used, then device ID may be omitted in the above hash function for calculating the local MACn'. Alternatively, if a partial AIoT device ID is received in step 6, then the partial AIoT device ID may be used in the hash function. For example, if the AIoT device is identified by a partial ID formed by its home network identifier and its owner identifier (which are received in step 6) , then the hash function may use this partial AIoT device ID.

[0247] If MACn (copy of MAC received from the reader) and MACn' (local copy calculated by AIoT device) are the same, then the MAC verification succeeds. Otherwise,  the verification fails, and the AIoT device may simply drop the message received in step 6 and stop.

[0248] If the MAC validation is successful, the A-IoT device may optionally generate user side MAC, MACu, based on a refreshed device side counter (e.g., increment by one after calculating the MACn') . For example, MACu = HASH (device ID, reader ID, refreshed counter, Kaiot) , where Kaiot is the initial key for the AIoT device that is locally stored on the A-IoT device. Note when using a counter in hash operation, it means using the value of the counter.

[0249] Step 10: The A-IoT device may send a service response message to the reader, as a response to the service message in step 6. The service response message may include an inventory response message, or a command response message. The service response message may carry at least one of: MACu; or device ID of the AIoT device (e.g., at instance level –with all 3GPP identifier included, which uniquely identify the AIoT device; or at another level) .

[0250] Note that if the refreshed device side counter (either after calculating MACn', if MACu is not calculated; or after calculating MACu if MACu is calculated) is equal to its initial value, then the service response message may carry a device side counter reset indicator.

[0251] Step 11: If MACu is carried in the service response message in step 8, the reader calculates the its local copy of MACu', in a similar way as the A-IoT device does in step 7, and verifies the validity of MACu' (i.e., whether MACu'equals to MACu received in step 9) . If the verification is successful, the service response message is determined as valid.

[0252] Note that before calculating the MACu', the reader needs to first increment its local copy of the network side counter.

[0253] Note that if the device side counter reset indicator is carried in the service response message in step 8, it indicates that the device side counter (maintained by AIoT device) is reset to its initial value. This give the reader a chance to make error correction in  case the network side counter is out of synchronization with the device side counter. For example, if the value of the network side counter is not initial value, the reception of the device side counter reset indicator will trigger the reader to reset the network side counter. In this case, the MACn'described above will be calculated using the initial counter value.

[0254] Step 12: The Reader may forward the service response message (e.g., inventory response message, or a command response message) to the A-IoT controller. The service response message may carry at least one of: MACu; device ID of the AIoT device; or reader ID. The service response message may also carry the latest value for the network side counter.

[0255] Step 13: A-IoT controller stores the device ID of the AIoT device, and the reader ID. Note that if there are multiple readers involved, one or more service response messages may be received by the AIoT controller. Based on the service response message (s) , the AIoT control may establish a record which store all the AIoT devices which are covered by the service response message (s) . The record may further store a reader ID corresponding to each AIoT device. The AIoT controller may then send a service response message (e.g., as a response to the service message in step 1) to the AF. The service response message may carry the AIoT device ID (s) and its corresponding reader (e.g., via a reader ID) . Note that one or more service response message (s) may be used.

[0256] The AIoT controller may update its local view of the network side counter value, if a network side counter value is received in step 10.

[0257] Step 14: The AIoT controller may send a message (e.g., counter notification message) to the ADSM, carrying its current view of the network side counter value. For example, this may be due to that a device side counter reset, or the AIoT device sends a MACu in its response message to the reader.

[0258] In this disclosure, various embodiments may be combined when there is no conflict. For example, in some example implementations, the MAC generation may use both a random number and a counter. In this case, the network (e.g., ADSM) may first  negotiate with the AIoT device on which parameter will be used.

[0259] In this disclosure, the counter used for calculating the MAC may be replaced by a time stamp, or a time counter which may be generated by the local time or international standard time. In this case, a counter reset indicator may not be required.

[0260] In this disclosure, when calculating a MAC, the AIOT device key may be the initial key provisioned to the AIoT device. However, the AIoT device and the core network (e.g., ADSM) may choose to use a variation of the AIoT device key, for increased security. For example, the AIoT device key may be transformed by the device side counter or the network side counter. The transformation may include, for example, concatenate the AIoT device key with the respective counter.

[0261] Performed by a wireless device, the method includes: receiving a first message from a first network element, the first message carrying at least one of: a first Message Authentication Code (MAC) ; a device ID of the wireless device; a portion of the device ID of the wireless device; a first random number; or a first counter reset indicator indicating that a network side counter is reset to an initial value; calculating via a hash function, a second MAC using at least one of following input: a key of the wireless device; the device ID of the wireless device; the portion of the device ID of the wireless device; an ID of a first network element which is in communication with the wireless device; the first random number; or a device side counter that is maintained by the wireless device; and determining whether the first MAC is valid or not by comparing the first MAC and the second MAC.

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

[0263] In any portion or combination of the implementations above, the first network element is a reader that is associated with the wireless device or serves the wireless device.

[0264] In any portion or combination of the implementations above, the first MAC is generated by one of: the first network element, or an AIoT controller.

[0265] In any portion or combination of the implementations above, the first message comprises at least one of: an inventory request; or a command comprising at least one of: a read command for reading data from the wireless device; a write command to write data to the wireless device; or a disable command to disable the wireless device.

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

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

[0268] 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) .

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

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

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

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

[0273] 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:receiving a first message from a first network element, the first message carrying at least one of: a first Message Authentication Code (MAC) ; a device ID of the wireless device; a portion of the device ID of the wireless device; a first random number; or a first counter reset indicator indicating that a network side counter is reset to an initial value;calculating via a hash function, a second MAC using at least one of following input: a key of the wireless device; the device ID of the wireless device; the portion of the device ID of the wireless device; an ID of a first network element which is in communication with the wireless device; the first random number; or a device side counter that is maintained by the wireless device; anddetermining whether the first MAC is valid or not by comparing the first MAC and the second MAC.2.The method of claim 1, wherein the wireless device is an AIoT device.3.The method of claim 1, wherein the first network element is a reader that is associated with the wireless device or serves the wireless device.4.The method of claim 1, wherein the first MAC is generated by one of: the first network element, or an AIoT controller.5.The method of claim 1, wherein the first message comprises at least one of:an inventory request; ora command comprising at least one of: a read command for reading data from the wireless device; a write command to write data to the wireless device; or a disable command to disable the wireless device.6.The method of any one of claims 1-5, wherein the first message is determined to be valid and the first message carries the first random number, the method further comprising:generating a second random number;calculating via the hash function, a third MAC using at least one of following input: the second random number; or the key of the AIoT device; andtransmitting, to the first network element, a second message as a response to the first message, the second message carrying at least one of: the second random number; or the third MAC.7.The method of any one of claims 1-5, wherein the first message is determined to be valid and the first message carries the first MAC, the method further comprising:increment the device side counter;calculating via the hash function, a third MAC using at least one of following input: the device side counter; or the key of the AIoT device; andtransmitting, to the first network element, a second message as a response to the first message, the second message carrying the third MAC.8.The method of claim 7, wherein after calculating the third MAC, the method further comprises incrementing the device side counter.9.The method of claim 8, wherein transmitting the second message comprises:in response to a value of the device side counter being the initial value after the incrementing, transmitting, to the first network element, the second message as the response to the first message, the second message carrying at least one of: the third MAC; or a second counter reset indicator indicating that the device side counter is reset to the initial value.10.The method of any one of claims 1-5, wherein the first message is determined to be valid and the first message carries the first counter reset indicator, and wherein determining whether the first MAC is valid or not comprises:resetting the device side counter to an initial value; andcalculating via the hash function, the second MAC using at least one of following input: the key of the wireless device; the device ID of the wireless device; the portion of the device ID of the AIoT device; the ID of a first network element; or the device side counter.11.The method of claim 10, wherein the initial value is predefined or configured by a core network entity.12.A method for wireless communication, performed by a first network element, comprising:calculating via a hash function, a first Message Authentication Code (MAC) for an Ambient Internet of Things (AIoT) device, using at least one of following input: a key of the AIoT device; a device identifier (ID) of the AIoT device; a portion of the device ID of the AIoT device; an ID of a second network element which is in communication with the AIoT device; a first random number; or a network side counter, wherein the network side counter is synchronized with a device side counter that is maintained by the AIoT device; andtransmitting, to the second network element identified by the ID of the second network element, a first message carrying at least one of: the first MAC; the device ID of the AIoT device; the portion of the device ID of the AIoT device; the first random number; or a first counter reset indicator indicating that the network side counter is reset to an initial value.13.The method of claim 12, wherein the first network element comprises an AIoT controller, and wherein the second network element comprises reader.14.The method of claim 13, wherein the AIoT controller is a core network (CN) entity in a CN of a wireless network.15.The method of claim 13, wherein the reader comprises at least one of: a base station; or an entity that is integrated with a User Equipment (UE) .16.The method of claim 12, wherein the first message comprises at least one of:an inventory request; ora command comprising at least one of: a read command for reading data from the AIoT device; a write command to write data to the AIoT device; or a disable command to disable the AIoT device.17.The method of any one of claims 12-16, wherein before calculating the first MAC, the method further comprises:receiving, from a third network element, a second message carrying at least one of: the device ID of the AIoT device; the portion of the device ID of the AIoT device, wherein the second message triggers the first network element to transmit the first message;transmitting, to a fourth network element, a fourth message carrying the device ID of the AIoT device; or the portion of the device ID of the AIoT device; andreceiving, from the fourth network element, a fifth message as a response to the fourth message, the fifth message carrying at least one of: the ID of the second network element; or the key of the AIoT device.18.The method of claim 17, wherein the fourth network element comprises an AIoT device security management entity.19.The method of claim 18, wherein the initial value is predefined or negotiated between the AIoT device and the AIoT device security management entity.20.The method of claim 18, further comprising:receiving, from the second network element, a sixth message as a response to the first message, the sixth message carrying at least one of: a second random number generated by the AIoT device; a second counter reset indicator indicating that the device side counter is reset to the initial value; the device side counter; or a second MAC that is calculated by the AIoT device based on the device side counter or the second random number.21.The method of claim 20, further comprising:determining whether the sixth message is valid or not; andin response to the sixth message being valid, transmitting a seventh message to the third network element as a response to the second message, the seventh message carrying at least one of: the device ID of the AIoT device; or the ID of the second network element.22.The method of claim 21, wherein the sixth message carries the second random number generated by the AIoT device, and wherein determining whether the sixth message is valid or not comprises:calculating via the hash function, a third MAC using at least one of following input: the second random number; or the key of the AIoT device; anddetermining that the sixth message is valid when the third MAC matches the second MAC.23.The method of claim 21, wherein the sixth message comprises the second MAC, and wherein determining whether the sixth message is valid or not comprises:calculating via the hash function, a third MAC using at least one of following input: the network side counter; or the key of the AIoT device; anddetermining that the sixth message is valid when the third MAC matches the second MAC.24.The method of claim 21, wherein the sixth message comprises the second MAC and the second counter reset indicator, and wherein determining whether the sixth message is valid or not comprises:determining whether the network side counter needs to be reset based on the second counter reset indicator and a current value of the network side counter;in a determination that the network side counter needs to be reset, resetting the network side counter;calculating via the hash function, a third MAC using at least one of following input: the network side counter; or the key of the AIoT device; anddetermining that the sixth message is valid when the third MAC matches the second MAC.25.The method of claim 21, further comprising:in response to the sixth message being valid, transmitting an eighth message to the fourth network element, the eighth message carrying a current value for the network side counter.26.A method for wireless communication, performed by a first network element, comprising:receiving, from a second network element, a first message comprising at least one of: a device ID of an Ambient Internet of Things (AIoT) device; a portion of the device ID of the AIoT device; a key of the AIoT device;calculating via a hash function, a first Message Authentication Code (MAC) for the AIoT device, using at least one of following input: the key of the AIoT device; the device ID of the AIoT device; the portion of the device ID of the AIoT device; an ID of a first network element; a first random number generated by the first network element; or a network side counter; andtransmitting, to the AIoT device, a second message comprising at least one of: the first MAC; the device ID of the AIoT device; the portion of the device ID of the AIoT device; the first random number; or a first counter reset indicator indicating that a network side counter is reset to an initial value.27.The method of claim 26, wherein the first network element comprises a reader, and wherein the second network element comprises an AIoT controller.28.The method of claim 27, wherein the AIoT controller is a core network (CN) entity in a CN of a wireless network.29.The method of claim 27, wherein the reader comprises at least one of: a base station; or an entity that is integrated with a User Equipment (UE) .30.The method of claim 26, wherein the first message comprises at least one of:an inventory request; ora command comprising at least one of: a read command for reading data from the AIoT device; a write command to write data to the AIoT device; or a disable command to disable the AIoT device.31.The method of any one of claims 26-30, further comprising:receiving, from the AIoT device, a third message as a response to the second message, the third message comprising at least one of: a second MAC generated by the AIoT device; a second random number generated by the AIoT device; or a second counter reset indicator indicating that a device side counter maintained by the AIoT device is reset to the initial value.32.The method of claim 31, wherein:the network side counter is maintained by a network element that is different from the AIoT device; andthe device side counter and the network side counter are synchronized with each other and are configured with a same initial value.33.The method of claim 31, further comprising:calculating a third MAC using at least one of following input: the key of the AIoT device; the second random number; or the network side counter;determining whether the second MAC is valid or not by comparing the second MAC and the third MAC; andin response to the second MAC being valid, transmitting, to the second network element, a fourth message as a response to the first message, the fourth message comprising at least one of: the device ID of the AIoT device; or the ID of the first network element.34.The method of claim 33, wherein the third message carries the second random number, and wherein calculating the third MAC comprises calculating the third MAC using following input: the key of the AIoT device; and the second random number.35.The method of claim 33, wherein the third message carries the second MAC, and wherein calculating the third MAC comprises:refreshing the network side counter by increment a value of the network side counter; andcalculating the third MAC using following input: the key of the AIoT device; and the network side counter.36.The method of claim 35, wherein the fourth message further carries a current value of the network side counter.37.The method of claim 33, wherein the third message carries the second counter reset indicator, and wherein calculating the third MAC comprises:resetting the network side counter to the initial value; andcalculating the third MAC using following input: the key of the AIoT device; and the network side counter.38.The method of claim 37, wherein the fourth message further carries a current value of the network side counter.39.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 of any one of claims 1-38.40.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-38.

Images