Communication method and device

Abstract

The present application relates to a communication method and a device. The communication method performed by an AIoT device comprises: receiving a request message from a read / write device, the request message carrying a temporary identifier for security protection of the AIoT device, and the temporary identifier being used for updating an identifier of the AIoT device.

Description

Communication methods and devices Technical Field

[0001] This application relates to the field of communications, and more specifically, to a communication method and apparatus. Background Technology

[0002] In related technologies, Ambient Powered IoT (AIoT) devices interact with AIoT functions through their corresponding readers or readers / writers. In this scenario, AIoT functions typically page AIoT devices using their identifiers. However, if the identifiers of AIoT devices are exposed over the air interface for extended periods, it may lead to problems such as easy tracking and / or linking of AIoT devices. Therefore, how to prevent the long-term exposure of AIoT device identifiers over the air interface to ensure the security of AIoT devices becomes a problem that needs to be solved. Summary of the Invention

[0003] This application provides a communication method and device.

[0004] This application provides a communication method executed by an AIoT device, including:

[0005] Receive a request message from a read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0006] This application provides a communication method executed by an AIoT function, including:

[0007] A request message is sent to the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0008] This application provides a communication method executed by a read / write device, including:

[0009] Receive a request message from the AIoT function, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device;

[0010] Send the request message to the AIoT device.

[0011] This application provides an AIoT device, including:

[0012] The first communication unit is configured to receive a request message from a read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0013] This application provides an AIoT function, including:

[0014] The second communication unit is used to send a request message to the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0015] This application provides a read / write device, including:

[0016] The third communication unit is configured to receive a request message from the AIoT function, wherein the request message carries a temporary identifier for the security protection of the AIoT device, the temporary identifier being used to update the identifier of the AIoT device; and to send the request message to the AIoT device.

[0017] This application provides an AIoT device, including a transceiver, a processor, and a memory. The memory stores a computer program, the transceiver communicates with other devices, and the processor calls and runs the computer program stored in the memory to enable the AIoT device to perform the methods described above.

[0018] This application provides an AIoT function, including a transceiver, a processor, and a memory. The memory stores a computer program, the transceiver communicates with other devices, and the processor calls and runs the computer program stored in the memory to enable the AIoT function to perform the methods described above.

[0019] This application provides a read / write device, including a transceiver, a processor, and a memory. The memory stores a computer program, the transceiver communicates with other devices, and the processor calls and runs the computer program stored in the memory to enable the read / write device to perform the methods described above.

[0020] This application provides a chip for implementing the above method.

[0021] Specifically, the chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to perform the methods described above.

[0022] This application provides a computer-readable storage medium for storing a computer program, which, when run by a device, causes the device to perform the above-described method.

[0023] This application provides a computer program product, including computer program instructions that cause a computer to perform the above-described method.

[0024] This application provides a computer program that, when run on a computer, causes the computer to perform the above-described method.

[0025] By adopting the above scheme, a temporary identifier can be allocated through a request message to update the identifier of the AIoT device. This refreshes the identifier of the AIoT device and avoids problems such as the AIoT device being easily tracked and / or linked due to the long-term transmission of the same AIoT device identifier over the air interface. Furthermore, since the temporary identifier is protected by security, it can be guaranteed that the updated temporary identifier will not be eavesdropped on or tampered with, thereby ensuring the security of the AIoT device.

[0026] Furthermore, the request message can carry a security-protected command to trigger the AIoT device to perform operations such as activation or deactivation. This is particularly suitable for situations where the AIoT function directly sends a request message containing a command to the AIoT device in a command-only flow, thereby shortening the interaction process between the AIoT device and the AIoT function; and because the command is security-protected, the security of the upper-layer data of the command transmitted between the AIoT function and the AIoT device can be guaranteed.

[0027] Furthermore, the request message can carry a message authentication code for authenticating the network. This allows network authentication to be performed on the AIoT device side, ensuring the reliability of the messages received by the AIoT device and consequently guaranteeing the security of the data reported by the AIoT device.

[0028] Furthermore, the response message returned by the AIoT device to the AIoT function can also carry securely protected response data of the AIoT device and / or an authentication response for authenticating the AIoT device. In this way, because the command is securely protected, the security of the data transmitted by the AIoT device can be guaranteed, and the network side can also authenticate the AIoT device by verifying the authentication response, further ensuring the security of the data obtained by the network side. Attached Figure Description

[0029] Figure 1 is a schematic diagram of an application scenario according to an embodiment of this application.

[0030] Figure 2 is a schematic flowchart of a communication method according to an embodiment of this application.

[0031] Figure 3 is a schematic flowchart of a communication method under a command-only flow according to an embodiment of the present application.

[0032] Figure 4 is a schematic flowchart of a communication method under a command-only flow according to another embodiment of this application.

[0033] Figure 5 is a schematic flowchart of a communication method under an inventory and command flow according to an embodiment of this application.

[0034] Figure 6 is a schematic flowchart of a communication method under an inventory and command flow according to another embodiment of this application.

[0035] Figure 7 is a schematic block diagram of an AIoT device according to an embodiment of this application.

[0036] Figure 8 is a schematic block diagram of an AIoT function according to an embodiment of this application.

[0037] Figure 9 is a schematic block diagram of a read / write device according to an embodiment of this application.

[0038] Figure 10 is a schematic block diagram of a communication device according to an embodiment of this application.

[0039] Figure 11 is a schematic block diagram of a chip according to an embodiment of this application. Detailed Implementation

[0040] The technical solutions of this application embodiment can be applied to various communication systems, such as: NR (New Radio), NR evolution, 6G (Sixth Generation Mobile Communications Technology), WLAN (Wireless Local Area Network), WiFi (Wireless Fidelity), or other communication systems.

[0041] This application describes various embodiments in conjunction with network devices and terminals. The terminal can be mobile or fixed, and may also be referred to as a mobile station, user unit, etc. The terminal can be a station in a WLAN, or a smart terminal, wireless modem, laptop, tablet, etc. In this application embodiment, the terminal can be a VR (Virtual Reality) terminal / AR (Augmented Reality) terminal, industrial control terminal, autonomous driving terminal, telemedicine terminal, smart grid terminal, transportation safety terminal, smart city terminal, or smart home wireless terminal, etc. By way of example and not limitation, in this application embodiment, the terminal can also be a wearable device.

[0042] In this embodiment, the network device can be a device for communicating with a terminal. The network device can be an access point in a WLAN, an evolved NR base station or a 6G base station, a relay station, or a vehicle-mounted device, wearable device, or a network device (gNB, the next generation Node B) in an NR network, or a network device in a future evolved PLMN (Public Land Mobile Network), or a network device in a non-terrestrial network, etc. By way of example and not limitation, in this embodiment, the network device can have mobility characteristics; for example, the network device can be a mobile device.

[0043] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0044] Figure 1 exemplarily illustrates a communication system 100. The communication system includes network devices 110 and terminals 120. In one possible implementation, the communication system 100 may include multiple network devices 110, and the coverage area of ​​each network device 110 may include multiple terminals 120; this embodiment does not limit this. In another possible implementation, the communication system 100 may also include other network entities such as mobility management entities and access and mobility management functions; this embodiment does not limit this. The network devices may further include access network devices and core network devices. That is, the communication system may also include multiple core networks for communicating with the access network devices. The access network devices may be NR systems or 6G base stations. Taking the communication system shown in Figure 1 as an example, the communication devices may include network devices and terminals with communication functions. The communication devices may also include other devices in the communication system, such as network controllers, mobility management entities, and other network entities; this embodiment does not limit this.

[0045] Figure 2 is a schematic flowchart of a communication method according to an embodiment of this application. In Figure 2, the communication method is described from the perspective of interaction between an AIoT device, a read / write device, and AIoT functions. The sending / receiving of the AIoT device corresponds to the receiving / sending of the read / write device, and the sending / receiving of the read / write device corresponds to the receiving / sending of the AIoT function. As shown in Figure 2, the communication method may include the following steps:

[0046] On the AIoT function side, S210 is executed to send a request message to the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0047] S220 to S230 are executed on the read / write device side, specifically:

[0048] S220. Receive a request message from the AIoT function, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device;

[0049] S230, Send the request message to the AIoT device.

[0050] On the AIoT device side, S240 is executed to receive a request message from the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0051] AIoT devices can be replaced by low-power devices, zero-power devices, or ordinary terminals, etc. This article does not limit or exhaustively list the various types of entities that AIoT devices may replace.

[0052] A read / write device can also be called a reader. Specifically, a read / write device can be one of the following: an access network device or a terminal; the access network device can include at least one of the following: a base station, a gNB, an eNB, network devices in a future PLMN network, network devices in an NTN network, a satellite, etc.

[0053] AIoT function can be represented as AIoTF (AIoT Function), which can also be replaced by AIoT NF (Network Function) or AIoT MF (Management Function), etc.

[0054] The processing of AIoT function request messages can be triggered by AF service requests (or business requests).

[0055] In some possible implementations, on the AIoT function side, the temporary identifier for security protection is obtained based on the security context of the AIoT device and the temporary identifier. Security protection may include encryption and / or integrity protection (hereinafter referred to as integrity protection).

[0056] On the AIoT device side, the processing after receiving the request message from the read / write device further includes: performing security verification on the temporary identifier of the security protection based on the security context of the AIoT device. This security verification may include integrity verification and / or decryption.

[0057] This temporary identifier refers to the updated temporary identifier assigned to the AIoT device this time. It can be simply referred to as the temporary identifier, or alternatively as the temporary identifier of this time or the temporary identifier of this update.

[0058] Temporary identifiers can be generated by the network, for example, by the AIoT function, or by other core network elements and obtained by the AIoT function from other core network elements.

[0059] The network side (such as AIoT functions or other core network elements) can generate temporary identifiers in the following ways: the network side uses its own generated random number as the temporary identifier; or, the network encrypts the temporary identifier using a key. Specifically, the network side encrypting the temporary identifier can be done by: the network side using its own symmetric key and / or fresh parameters to encrypt and calculate the temporary identifier with the permanent identifier of the AIoT device; or the network using its own public key and / or fresh parameters to encrypt and calculate the temporary identifier with the permanent identifier of the AIoT device. This is not limited to any particular method.

[0060] The security context of the AIoT device can be the NAS security context of the AIoT device. This NAS security context may include at least one of the security parameters corresponding to the AIoT device, such as a NAS (Non-Access Layer) key and a NAS security algorithm. The NAS key may include a NAS integrity protection key (hereinafter referred to as the NAS integrity key) and / or a NAS confidentiality key (or NAS encryption key). The NAS integrity key and the NAS confidentiality key may be the same or different; this embodiment does not impose any limitations. The NAS security algorithm may include a NAS integrity protection algorithm and / or a NAS encryption (decryption) algorithm.

[0061] The method of obtaining the security context of the AIoT device on the AIoT function side is not limited in this embodiment. It can be either stored by the AIoT function itself or obtained by the AIoT function from other core network elements. Other core network elements may include at least one of AMF, AUSF, AIoT UDM (hereinafter referred to as ADM).

[0062] Optionally, security protection includes encryption only, while security verification includes decryption.

[0063] Security protection measures on the AIoT functional side can include encrypting a temporary identifier based on a NAS encryption algorithm and the NAS confidentiality key corresponding to the AIoT device, resulting in an encrypted temporary identifier. In this case, the temporary identifier for security protection of the AIoT device can be an encrypted temporary identifier.

[0064] Security verification on the AIoT device side can include: decrypting the encrypted temporary identifier based on the NAS decryption algorithm and the NAS confidentiality key corresponding to the AIoT device; if the AIoT device successfully decrypts, it saves the temporary identifier and confirms successful security verification. Alternatively, it can also include: if the AIoT device fails to decrypt, it determines that the security verification has failed.

[0065] Optionally, security protection may include encryption and integrity protection, and security verification may include integrity verification and decryption.

[0066] The temporary identifier for security protection may include: an encrypted temporary identifier and a security verification code.

[0067] In one scenario, on the AIoT function side, encryption processing can be performed first, followed by integrity verification processing. The security protection processing of AIoTF can include: encrypting the temporary identifier based on the NAS encryption algorithm and the NAS confidentiality key corresponding to the AIoT device to obtain an encrypted temporary identifier; and calculating the integrity verification code based on the NAS integrity verification algorithm, the NAS integrity verification key, and the encrypted temporary identifier.

[0068] The security verification process on the AIoT device side can include: calculating a security verification code based on the NAS security algorithm, the NAS security key, and an encrypted temporary identifier; determining that the integrity verification is successful if the security verification code and the security check code are the same; and decrypting the encrypted temporary identifier based on the NAS decryption algorithm and the NAS confidentiality key corresponding to the AIoT device; and saving the temporary identifier and determining that the security verification is successful if the decryption is successful. Alternatively, it can also include: determining that the security verification has failed if the AIoT device fails to decrypt and / or fails to verify the integrity.

[0069] In one scenario, on the AIoT function side, integrity verification can be performed first, followed by encryption. The security protection process of AIoTF can include: calculating an integrity verification code based on the NAS integrity verification algorithm, the NAS integrity key corresponding to the AIoT device, and a temporary identifier; encrypting the temporary identifier based on the NAS encryption algorithm and the NAS confidentiality key corresponding to the AIoT device to obtain an encrypted temporary identifier.

[0070] Security verification on the AIoT device side can include: decrypting the encrypted temporary identifier using the NAS decryption algorithm and the NAS confidentiality key corresponding to the AIoT device; if decryption is successful, obtaining the temporary identifier; calculating the integrity verification code using the NAS integrity algorithm, the NAS integrity key, and the temporary identifier; if the integrity verification code and the integrity check code are the same, saving the temporary identifier and confirming successful security verification. Alternatively, it can also include: if the AIoT device fails decryption and / or integrity verification, determining that security verification has failed.

[0071] Optionally, security protection may include integrity-only protection, and security verification may include integrity verification. In this case, the temporary identifier for security protection may include a temporary identifier and an integrity verification code.

[0072] The security protection process for AIoT functions may include: a security verification code calculated based on the NAS security algorithm, the NAS security key corresponding to the AIoT device, and the temporary identifier.

[0073] The security verification process on the AIoT device side can include: calculating a security verification code based on the NAS security algorithm, the NAS security key corresponding to the AIoT device, and a temporary identifier; if the security verification code and the security check code are the same, saving the temporary identifier and confirming successful security verification. Alternatively, it can also include: if the security verification code and the security check code are different, determining that the security verification has failed.

[0074] In one embodiment, if the temporary identifier of the security protection is successfully verified, the AIoT device updates the identifier of the AIoT device.

[0075] In this embodiment, updating the AIoT device's identifier can refer to the AIoT device storing a temporary identifier locally as the temporary identifier for this update. Specifically, storing the temporary identifier can include: the AIoT device storing the obtained temporary identifier locally in writeable non-volatile memory (writeable-NVM) that is not lost when power is off.

[0076] For example, assuming that before obtaining the current temporary identifier (e.g., Temp ID_n), the AIoT device still stores the previous temporary identifier (i.e., the previously updated temporary identifier, e.g., Temp ID_n-1) in its local writeable-NVM, then the AIoT device writes Temp ID_n into the writeable-NVM and deletes Temp ID_n-1 stored in the writeable-NVM. The deletion of Temp ID_n-1 can be performed before or after writing Temp ID_n; this is not limited here. Alternatively, assuming that before obtaining the current temporary identifier (Temp ID_n), the AIoT device does not store any temporary identifiers in its local writeable-NVM, then the AIoT device directly writes Temp ID_n into the writeable-NVM.

[0077] In one embodiment, the processing of the AIoT device may further include: sending a response message to the AIoT function through the read / write device, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, and the initial identifier of the AIoT device.

[0078] The processing of the read / write device further includes: sending a response message from the AIoT device to the AIoT function, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, and the initial identifier of the AIoT device.

[0079] The processing of the AIoT function may further include: receiving a response message sent by the AIoT device through the read / write device, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, and the initial identifier of the AIoT device.

[0080] The temporary identifier for AIoT devices can be the current temporary identifier (i.e., the temporary identifier updated this time) or the previous temporary identifier (i.e., the temporary identifier updated last time).

[0081] The initial identifier of the AIoT device includes the initial temporary identifier of the AIoT device or the permanent identifier of the AIoT device.

[0082] In one example, the AIoT device sends a response message after successfully verifying the security of the temporary identifier for the security protection (or after the AIoT device saves the temporary identifier locally).

[0083] Optionally, the response message may only carry information indicating a successful update of the temporary identifier. Accordingly, the AIoT function may maintain the current temporary identifier upon receiving information indicating a successful update.

[0084] The AIoT function maintains the temporary identifier for this update in the following ways: The AIoT function saves the temporary identifier updated for the AIoT device this time. It should be noted that while saving the temporary identifier for this update, the AIoT function may still maintain the temporary identifiers of the AIoT device from the last or previous updates, or the AIoT function may no longer maintain the temporary identifiers of the AIoT device from the last or previous updates.

[0085] Furthermore, the maintenance of this temporary identifier by the AIoT function may also include: the AIoT function carrying this temporary identifier when sending a new request message to page the AIoT device.

[0086] Optionally, the response message may carry the current temporary identifier of the AIoT device to implicitly indicate that the AIoT device has successfully updated the temporary identifier. Accordingly, the AIoT function may maintain the current temporary identifier upon receiving it from the AIoT device.

[0087] Optionally, the response message may carry the previous temporary identifier. Accordingly, upon receiving the previous temporary identifier, the AIoT function can determine that the AIoT device has successfully updated its temporary identifier and maintain the current temporary identifier of the AIoT device.

[0088] Optionally, the response message may carry an encrypted permanent identifier of the AIoT device to implicitly indicate that the AIoT device has successfully updated its temporary identifier.

[0089] The encrypted permanent identifier is obtained by encrypting the permanent identifier based on a shared key between the AIoT device and the AIoT function.

[0090] Accordingly, the processing of the AIoT function after receiving a response message carrying an encrypted permanent identifier of the AIoT device may include: decrypting the encrypted permanent identifier based on the shared key between the AIoT device and the AIoT function; if decryption is successful, determining that the AIoT device has successfully updated the temporary identifier, and maintaining this temporary identifier, i.e., maintaining the updated temporary identifier. Alternatively, it may include: if decryption fails, determining that the AIoT device failed to update the temporary identifier, and still maintaining the previous temporary identifier of the AIoT device; or, if decryption fails and the AIoT function does not locally store any successfully updated temporary identifier of the AIoT device, determining that the AIoT device failed to update the temporary identifier.

[0091] The shared key between the AIoT device and the AIoT function is pre-stored on both the AIoT function and the AIoT device side.

[0092] In one scenario, the shared key may be pre-configured by the operator for both the AIoT function and the AIoT device.

[0093] In one scenario, the shared key may be sent by the AF to the AIoT function and stored in the AIoT function before the AF sends this service request. In this case, the shared key stored on the AIoT device side may be pre-configured by the AF.

[0094] In one scenario, the shared key can be a key generated by a network element performing AIoT device authentication. This network element may include at least one of the following: an AIoT function, an AUSF (Automatic Access Provider), an ADM (Automatic Device Authentication Center), or a third-party AAA server. In this scenario, if the AIoT function is one of the network elements performing AIoT device authentication, it directly obtains the shared key locally; if the AIoT function is not one of the network elements performing AIoT device authentication, it can obtain the shared key from at least one of the AUSF, ADM, or a third-party AAA server.

[0095] In one scenario, the shared key may be carried by the AF when sending a service request (or business request) to the AIoT function. In this case, the AIoT function may extract and save the shared key from the service request after receiving it. The shared key saved on the AIoT device side may be pre-configured by the AF. That is, in this scenario, the shared key can be shared by the AF, the AIoT function, and the AIoT device.

[0096] In actual processing, the response message may also carry at least two of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, and the encrypted permanent identifier of the AIoT device. For example, the response message may carry information indicating successful update of the temporary identifier and the updated temporary identifier of the AIoT device; or, the response message may carry information indicating successful update of the temporary identifier and the previous temporary identifier. This is not limited or exhaustive.

[0097] In this way, the temporary identifier of the AIoT device can be updated by requesting the allocation of a secure temporary identifier for the AIoT device. This avoids the problem of the AIoT device being easily tracked and / or linked due to the long-term transmission of the same temporary identifier over the air interface. Furthermore, since the updated temporary identifier of the AIoT device is securely protected, it can be guaranteed that the updated temporary identifier of the AIoT device will not be eavesdropped on or tampered with, thereby ensuring the security of the AIoT device.

[0098] In one example, the AIoT device sends a response message after the security verification of the temporary identifier for the security protection fails and / or the writing of the temporary identifier fails.

[0099] Optionally, the response message may carry the initial identifier of the AIoT device or the previous temporary identifier to implicitly indicate that the update of the temporary identifier has failed.

[0100] Optionally, the response message may carry the initial identifier or the previous temporary identifier of the AIoT device, and may also carry an indication (such as NACK) to indicate that the update of the temporary identifier failed, so as to explicitly indicate that the update of the temporary identifier failed.

[0101] After the AIoT function receives a response message that explicitly or implicitly indicates that the update of the temporary identifier has failed, the AIoT function may end the processing and / or resend a new request message, without limitation.

[0102] In some possible implementations, the request message may carry the initial identifier of the AIoT device. The initial identifier of the AIoT device may be an initial temporary identifier or a permanent identifier of the AIoT device.

[0103] This implementation is particularly applicable to situations where the AIoT device and the AIoT function lose synchronization regarding temporary identifiers. In such cases, the AIoT function can use the initial identifier of the AIoT device to page the AIoT device (i.e., carry the initial identifier of the AIoT device in the request message).

[0104] Accordingly, the response message sent by the AIoT device can carry the initial identifier of the AIoT device, that is, the AIoT device uses the initial identifier to respond to the AIoT function.

[0105] In some possible implementations, the request message can be a message in a command-only process or pattern.

[0106] Command-only mode can be understood as follows: the network (such as AIoT RF and / or read / write devices) directly sends a request message containing a command to the AIoT device. The AIoT device executes the operation indicated by the command (read, write, disable, enable) and then returns a response to the network. This command-only mode can also be understood as the network including a specific command in the paging request (i.e., request message) of the paging device. The AIoT device not only needs to report its identifier but also needs to execute the corresponding operation of the command. It should be noted that command-only mode must be executed in some scenarios. For example, in the process of enabling an AIoT device, when the AIoT device temporarily disables itself, its RF transmission function is temporarily suspended, and the AIoT device cannot send messages to the network. If the inventory and command process is executed to wake up the AIoT device, since inventory requires the AIoT device to report its identifier, the AIoT device with its RF transmission function suspended cannot report its identifier, making it uncertain whether the network can page the device. Therefore, the command process cannot continue, and command-only mode must be used. In some possible examples, the command-only pattern can also be replaced by an inventory process or pattern that carries commands.

[0107] In addition, the command-only process is concise. Since the command request and response contain upper-layer data (AIoT specific NAS), security protection needs to be enabled when the AIoT device interacts with the network.

[0108] Referring to Figure 3, taking the RAN (Radio Access Network) as an example, the communication method under the command-only flow is explained:

[0109] Step 301: The AIoT function receives the service request from AF.

[0110] Step 302: Select the AIoT function to read / write device RAN (also known as RAN reader, BS Reader, or AIoT RAN reader).

[0111] Step 303: The AIoT function sends a request message to the RAN, the request message carrying a temporary identifier for security protection of the AIoT device; and the request message also carrying a security protection command. Optionally, the request message may also carry a message authentication code for authenticating the network. Optionally, the request message may also carry one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier. The previous temporary identifier refers to the last updated temporary identifier of the AIoT device.

[0112] Step 304: RAN sends a request message to the AIoT device.

[0113] Step 305: If the AIoT device authentication is successful, execute the corresponding command operation. Successful authentication may include successful command verification and / or successful network authentication.

[0114] Step 306: The AIoT device sends a response message to the AIoT function via the RAN.

[0115] Step 307: The AIoT function sends a service response to the AF.

[0116] Optionally, in step 301, as shown in Figure 3, the AIoT function can receive service requests from the AF forwarded by the NEF. The NEF's processing may include: the NEF receiving the service request from the AF, determining the AIoT function based on the AF's service request, and forwarding the AF's service request to the AIoT function. This embodiment does not limit the specific method by which the NEF determines the AIoT function.

[0117] Optionally, in step 301, the AIoT function can directly receive service requests from AF.

[0118] The service request in step 301 may carry at least one of the following: parameters of the AIoT device, parameters of the read / write device (RAN in this embodiment), and service operation-specific parameters.

[0119] The parameters of the AIoT device may include at least one of the following: the identifier of the AIoT device, the location of the AIoT device, etc. The identifier of the AIoT device may be a permanent identifier of the AIoT device.

[0120] The parameters of the read / write device may include at least one of the following: the identifier of the read / write device, the serial number of the read / write device, and the location of the read / write device.

[0121] The service operation-specific parameters may include at least one of the following: service type indication information, or a command. The service type indication information can be used to indicate the service type; in this embodiment, the service type is command-only.

[0122] In step 302, the AIoT function determines or selects the read / write device RAN based on at least one of the identifier, number, and location of the read / write device in the service request.

[0123] In addition, before performing step 303, the AIoT function may perform at least one of the following: determine the identifier of the A-IoT device based on the service request, which will be included in the paging message on the AIoT wireless interface to locate the AIoT device; determine the service type.

[0124] The AIoT function can determine the service type in two ways: First, if the request message includes a service type indication, the AIoT function determines the type of service to be executed based on this indication. Second, if the request message does not include a service type indication, the AIoT function determines the service type based on the AIoT device's identifier and the specific type of the command. For example, the AIoT function can determine that a device needs to be enabled based on the service type indication and the AIoT device's identifier carried in the service request from the AF, thus determining that a command-only service needs to be executed. As another example, the AIoT function can determine that a device needs to be enabled based on the commands carried in the service request from the AF, including the enable command and the AIoT device's identifier carried in the service request, thus determining that a command-only service needs to be executed.

[0125] In step 303, the AIoT function can send a request message to the Read / Write Device (RAN) through other core network elements. These other core network elements may include AMF (Access and Mobility Management Function), etc.

[0126] The request message may carry a temporary identifier for the security protection of the AIoT device; and the request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activation or deactivation.

[0127] The description of the temporary safety protection sign is the same as that in the previous embodiments and will not be repeated here.

[0128] A command is the command carried in the service request of an AF.

[0129] Commands can include activation commands, or simply activation or enable commands. The activation command is used to trigger the activation of the AIoT device. Activation can refer to enabling the radio frequency (RF) function of the AIoT device. For example, before receiving a request message, the AIoT device may be in a temporarily deactivated state, meaning its RF function is temporarily disabled. If the AIoT device receives an activation command, it will switch its RF function from the temporarily deactivated state to the activated state (or enable the RF function).

[0130] The command can be the deactivation command.

[0131] The deactivation command can include a temporary deactivation (disable) command, which triggers the temporary deactivation of the AIoT device, meaning the AIoT device temporarily disables its radio frequency function. Alternatively, the deactivation command can include a permanent deactivation command, which triggers the permanent deactivation of the AIoT device, meaning the AIoT device permanently disables its radio frequency function.

[0132] Optionally, in addition to including activation or deactivation commands, the command may also include read and / or write commands. The read command triggers the AIoT device to read data; the write command triggers the AIoT device to write data.

[0133] It should be understood that a command may include only one of the above; or, a command may include multiple of the above, such as an activation command, a read command, or an activation command, a write command, etc., without limitation or exhaustive list.

[0134] Security protection may include encryption and / or integrity protection.

[0135] Optionally, the security protection command includes at least an encrypted command. The security protection command is obtained by encrypting the command based on a shared key between the AIoT device and the AIoT function. Here, the security protection command is the encrypted command. The description of the shared key is the same as in the previous embodiments and will not be repeated. This embodiment does not limit the encryption algorithm used for the encrypted command.

[0136] Optionally, the security protection command may include an encrypted command and a corresponding integrity verification code. The calculation method for the encrypted command is the same as in the aforementioned embodiments and will not be repeated here.

[0137] If integrity verification is performed before encryption, the integrity verification code corresponding to the command can be calculated based on the shared key between the AIoT device and the AIoT function, and the command. This embodiment does not limit the integrity verification algorithm used to calculate the integrity verification code; as long as the AIoT function and the AIoT device use the same integrity verification algorithm, it is within the protection scope of this embodiment.

[0138] If encryption is performed before the completion verification is executed, the completion verification code corresponding to the command can be calculated based on the shared key between the AIoT device and the AIoT function and the encrypted command.

[0139] For example, the request message may also carry one of the following: the previous temporary identifier, or the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier. That is, in addition to carrying a temporary identifier for security protection and a security protection command, the request message may also carry the previous temporary identifier or the initial identifier in plaintext.

[0140] In one scenario, before sending a request message, the AIoT function can retrieve the previous temporary identifier locally (i.e., the last updated temporary identifier of the AIoT device stored locally). If the AIoT function cannot retrieve the previous temporary identifier locally, it can ensure that at least the AIoT device is paged by including the initial identifier of the AIoT device in the request message.

[0141] The reason why the AIoT function cannot retrieve the previous temporary identifier locally may be due to the loss of synchronization of the temporary identifier or the fact that the AIoT device has not been assigned a temporary identifier. Among them, the loss of synchronization of the temporary identifier may be because the AIoT device switched the AIoT function of the service, and the switched AIoT function may not have stored any temporary identifiers assigned to the AIoT device.

[0142] On the AIoT function side, the initial temporary identifier of the AIoT device can be obtained by the AIoT function from at least one of the following: an external AF, a core network device (such as a certificate holder within the core network), or an external AAA server. On the AIoT function side, the timing of obtaining the initial temporary identifier of the AIoT device is within the protection scope of this embodiment as long as it occurs before sending the request message.

[0143] In one scenario, before sending a request message, the AIoT function can retrieve the previous temporary identifier locally. If the AIoT function finds the previous temporary identifier locally, it can page the AIoT device by including the previous temporary identifier in the request message. For example, the AIoT function could include the previous temporary identifier in the request message if synchronization with the AIoT device is lost, provided that the previous temporary identifier is stored locally.

[0144] Optionally, the previous temporary identifier can be any inventory and command process before the current AIoT function sends the request message (i.e., the request message carrying the temporary identifier of this security protection), or the temporary identifier of the AIoT device that was successfully updated in any command-only process before the current AIoT function sends the request message.

[0145] Specifically, the request message is sent during any inventory and command process or any command-only process prior to the current request message sent by the AIoT function. This request message carries the previous temporary identifier assigned to the AIoT device. After the AIoT device writes the previous temporary identifier, it returns a response message to the AIoT function. The content that the response message may carry is similar to that in the aforementioned embodiments. For example, the response message may carry at least one of the following: information indicating successful update of the temporary identifier, the previous temporary identifier, or the encrypted permanent identifier of the AIoT device. This will not be elaborated here. When the AIoT function receives the response message, it can determine that the previous temporary identifier was successfully updated, and the AIoT function maintains the previous temporary identifier.

[0146] Optionally, the previous temporary identifier could be a temporary identifier from which the AIoT device was successfully paged in any inventory process prior to the current AIoT function sending the request message (i.e., the request message carrying the temporary identifier for this security protection). In other words, the AIoT function may have successfully updated the temporary identifier of the AIoT device during an inventory and command process, or only during the command process, and then the AIoT function can use this previously updated temporary identifier to page the AIoT device in a subsequent inventory process.

[0147] Specifically, during any inventory process prior to the current request message sent by the AIoT function, the read / write device is triggered to send a request message (such as a paging message) to the AIoT device. This request message carries the previous temporary identifier. The AIoT device returns a response message to the AIoT function. The content carried in this response message is similar to that in the aforementioned embodiments, such as carrying the previous temporary identifier of the AIoT device, which will not be elaborated further. In this case, the temporary identifier of the successfully paged AIoT device is the same as the previous temporary identifier.

[0148] For example, the request message also carries a Message Authentication Code (MAC) for authenticating the network. That is, in addition to carrying a temporary identifier for security protection and a command for security protection, the request message may also carry the previous temporary identifier, the initial identifier, or the MAC in plaintext.

[0149] Specifically, before sending a request message, the AIoT function can obtain authentication parameters related to the AIoT device. These authentication parameters may include the MAC address used for authenticating the network for the AIoT device; furthermore, these authentication parameters may also include the XRES (expected response) used for network authentication of the AIoT device. This embodiment does not limit the specific method by which the AIoT function obtains authentication parameters related to the AIoT device.

[0150] It should be noted that in some scenarios, such as when AIoT devices are Type I devices (i.e., with low rated power) and may not be able to support a lot of computation, the MAC address may not need to be included in the request message.

[0151] When the AIoT function sends a request message to the reader / writer device, it may further include: sending service type indication information to the reader / writer device, wherein the service type indication information is used to indicate the service type corresponding to the command. Correspondingly, when the reader / writer device receives the request message, it may further include: receiving service type indication information from the AIoT function, wherein the service type indication information is used to indicate the service type corresponding to the command.

[0152] Specifically, step 303 of the AIoT function execution may include: the AIoT function sending a downlink message to the Reader-Writer Device (RAN), or the AIoT function sending a downlink message to the Reader-Writer Device (RAN) through the AMF, wherein the downlink message carries a downlink NAS message and service type indication information, and the NAS message carries the request message. The downlink NAS message in the downlink message may be encapsulated in a downlink NASC (NAS container), which will be used in the following description for simplicity.

[0153] It should be noted that this is only an illustrative example. In actual processing, in addition to carrying downlink NACS (carrying request message) and service type indication information, the downlink message may also carry the previous temporary identifier or the initial identifier of the AIoT device. This embodiment does not limit or exhaustively list these possibilities.

[0154] In step 304, the request message sent by the read / write device can be an AIoT paging message or a paging message. This request message can also be carried within the NASC (Downlink NAS Message). That is, the read / write device can receive downlink messages from the AIoT function, extract the downlink NASC from the downlink messages, and then send it. Correspondingly, the AIoT device receiving the request message from the read / write device means that the AIoT device receives the request message carried by the downlink NAS message (downlink NASC) from the read / write device.

[0155] In step 305, the processing after the AIoT device receives the request message may include authentication processing by the AIoT device.

[0156] AIoT devices can perform command verification to implicitly determine whether network authentication was successful.

[0157] If the security protection command carried in the request message includes an encrypted command, the authentication process of the AIoT device may include: decrypting the security protection command based on the shared key between the AIoT device and the AIoT function; and verifying the command successfully if the decryption is successful.

[0158] If the security protection command carried in the request message includes an encrypted command and a corresponding integrity verification code, the authentication process of the AIoT device may include: decrypting the encrypted command based on the shared key between the AIoT device and the AIoT function; if decryption is successful, calculating the integrity verification code based on the shared key and the command; if the integrity verification code and the integrity verification code corresponding to the command are the same, the command is successfully verified; or, calculating the integrity verification code based on the shared key and the encrypted command; if the integrity verification code and the integrity verification code corresponding to the command are the same, decrypting the encrypted command based on the shared key between the AIoT device and the AIoT function; if decryption is successful, the command is successfully verified. This embodiment does not limit the decryption algorithm used to decrypt the command, as long as the decryption algorithm used by the AIoT device corresponds to the encryption algorithm used by the AIoT function, it is within the protection scope of this embodiment.

[0159] Furthermore, if the command verification is successful, the AIoT device can implicitly determine that the network authentication is successful and execute the corresponding operation of the command. The operation executed by the AIoT device is related to the specific content of the command, which has been described in the foregoing embodiments and will not be repeated here.

[0160] Optionally, the AIoT device can perform network authentication. Specifically, if the request message also carries a message authentication code for authenticating the network, the AIoT device's authentication process may include: calculating a message checksum; and if the message checksum matches the message authentication code, determining that network authentication is successful. The method by which the AIoT device calculates the message checksum should be the same as the method by which the network calculates the message authentication code; this is not limited here.

[0161] An AIoT device can perform both command verification and message authentication code authentication. This embodiment does not limit the order in which the AIoT device performs these two processes. Furthermore, the AIoT device can execute the corresponding command operation if the authentication network is successful.

[0162] Optionally, the request message may also carry a temporary identifier for security protection. In step 305, the processing of the AIoT device after receiving the request message may include: the AIoT device may perform security verification on the temporary identifier for security protection, and if the security verification is successful, update and save the temporary identifier. The specific description of the AIoT device performing security verification and saving the temporary identifier (i.e., saving the current temporary identifier or saving the updated temporary identifier) ​​is the same as in the previous embodiments, and will not be repeated here.

[0163] The processing of storing temporary identifiers by the AIoT device can be performed before or after successful command verification (or before or after successful command verification and successful network authentication), and before executing the corresponding operation of the command.

[0164] Optionally, the request message may also carry the previous temporary identifier or the initial identifier of the AIoT device. In step 305, the processing of the AIoT device after receiving the request message may include: if the previous temporary identifier or the initial identifier of the AIoT device carried in the request message is the same as the previous temporary identifier or the initial identifier stored in the device's own database, the AIoT device determines that the request message is for paging itself. Further, if the AIoT device determines that the request message is for paging itself, it may perform command verification (or command verification and network authentication) and execute the corresponding command operation; optionally, before executing the command-related operation, it may also perform the process of saving the temporary identifier, i.e., saving the temporarily updated identifier, which will not be repeated here.

[0165] If, in step 305, the AIoT device fails to verify the command and / or the message authentication code, it can still send an authentication failure response to the AIoT function via the read / write device; and the AIoT device will not execute the corresponding command operation. Accordingly, the AIoT function receives the authentication failure response sent by the AIoT device via the read / write device. After receiving the authentication failure response, the AIoT function can perform at least one of the following: acknowledge the command-only process failure, resend the request message, or send a notification to the AF that the AIoT device's authentication network failed, etc.

[0166] In step 306, the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, or the initial identifier of the AIoT device. The explanations regarding the content carried in the response message are the same as in the previous embodiments and will not be repeated.

[0167] Furthermore, the response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device.

[0168] The authentication response can be represented as RES. This embodiment does not limit the specific way that the AIoT device calculates RES.

[0169] The response data of the AIoT device can be the relevant response data after the AIoT device executes the corresponding operation of the command.

[0170] Optionally, after an AIoT device executes a command, it may need to return response data.

[0171] For example, when the command includes an activation command, the response data of the AIoT device may include a confirmation response of AIoT device activation; when the command includes a permanent deactivation or temporary deactivation command, the response data of the AIoT device may include a confirmation response of AIoT device deactivation (permanent deactivation or temporary deactivation).

[0172] For example, if the command includes an activation command and a read command, the response data of the AIoT device may only include the data read by the AIoT device, or may include the data read by the AIoT device and a confirmation response for the activation of the AIoT device; if the command includes an activation command and a write command, the response data of the AIoT device may include at least one of the confirmation response for the write data by the AIoT device and the confirmation response for the activation of the AIoT device.

[0173] In this case, the response message may carry at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, an authentication response for authenticating the AIoT device, and response data of the AIoT device for security protection.

[0174] Optionally, after an AIoT device executes a command, it may not need to return a response.

[0175] For example, when the command includes a write command, a permanent deactivation command, or a temporary deactivation command, the AIoT device may directly execute the corresponding write data or deactivation operation (temporary deactivation operation or permanent deactivation operation) without needing to return response data. In this case, the response message may carry at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, and an authentication response for authenticating the AIoT device.

[0176] The security protection response data is obtained by processing the response data based on the shared key between the AIoT device and the AIoT function.

[0177] Optionally, the security protection response data may include encrypted response data, which is obtained by encrypting the response data based on a shared key between the AIoT device and the AIoT function. The description of this shared key is the same as that of the shared key used in the encryption command, and will not be repeated here.

[0178] Optionally, the security protection response data may include encrypted response data and a corresponding integrity verification code. The calculation method for the encrypted response data is the same as in the aforementioned embodiments and will not be repeated here.

[0179] If integrity verification is performed before encryption, the integrity verification code corresponding to the response data can be calculated based on the shared key between the AIoT device and the AIoT function, and the response data. This embodiment does not limit the integrity verification algorithm used to calculate the integrity verification code; as long as the AIoT function and the AIoT device use the same integrity verification algorithm, it falls within the protection scope of this embodiment.

[0180] If encryption is performed before the completion verification is executed, the completion verification code corresponding to the response data can be calculated based on the shared key between the AIoT device and the AIoT function and the encrypted response data.

[0181] The response message sent by the AIoT device can also be carried in the uplink NAS message (or encapsulated in the uplink NASC).

[0182] Furthermore, the AIoT device can send response messages to the AIoT function through the read / write device, which can be: the AIoT device sends response messages to the AIoT function through the read / write device and other core network elements (such as AMF).

[0183] Optionally, the AIoT function may directly execute step 307 after receiving the response message. The service response may carry at least one of the following: response data, or a permanent identifier of the AIoT device.

[0184] Before sending a service response, the AIoT function can also perform security verification on the response data for security protection.

[0185] If the security-protected response data only includes encrypted response data, the AIoT function can decrypt the encrypted response data based on a shared key. If decryption is successful, the security verification is considered successful, and the response data has been obtained. Furthermore, the AIoT function can send the response data to the AF (Automatic Field Control).

[0186] When the security protection response data only includes encrypted response data and the corresponding integrity verification code, the AIoT function can perform the following processing: decrypt the encrypted response data based on the shared key; if decryption is successful, calculate the integrity verification code based on the response data and the shared key; if the integrity verification code and the integrity verification code corresponding to the response data are the same, the security verification is successful and the response data is obtained; or, calculate the integrity verification code based on the encrypted response data and the shared key; if the integrity verification code and the integrity verification code corresponding to the response data are the same, decrypt the encrypted response data based on the shared key; if decryption is successful, the security verification is successful and the response data is obtained. Furthermore, after successful security verification, the AIoT function can send the response data to the AF.

[0187] Optionally, if the response message includes an authentication response for authenticating the AIoT device, then before the AIoT function executes step 307, it may further include: if the expected response is the same as the authentication response, determining that the AIoT device authentication was successful. The method for obtaining this expected response has been described in the foregoing embodiments and will not be repeated here. Further, if the AIoT function determines that the AIoT device authentication was successful, step 307 is executed.

[0188] Additionally, it may include: if the AIoT function determines that the authentication of the AIoT device has failed when the expected response differs from the authentication response. After the AIoT function fails to authenticate the AIoT device, it may perform at least one of the following: confirm that the execution of the command-only process has failed, resend the request message, or send a notification to the AF that the authentication of the AIoT device has failed.

[0189] Furthermore, the behavior or methods of storing various identifiers on the AIoT device side are explained:

[0190] The ID storage within an AIoT device must store the device's permanent identifier in read-only non-volatile memory (NVM); alternatively, Temp ID_initial (the device's initial temporary identifier) ​​can be stored in the read-only NVM.

[0191] Additionally, the writeable-NVM of the AIoT device needs to store the temporary identifier assigned to it by AIoTF. For example, after the AIoT device receives the updated temporary identifier (e.g., Temp ID_n) assigned in the command-only request message in step 305, it writes Temp ID_n to the writeable-NVM and deletes the old temporary identifier Temp ID_n-1 from the writeable-NVM. After the AIoT device successfully writes the updated temporary identifier, the response message returned to AIoTF in step 306 can include ACK to indicate that the device's temporary identifier update was successful, or the updated temporary identifier Temp ID_n.

[0192] Referring to Figure 4, taking the UE (or UEreader) as the read / write device as an example, the communication method under the command-only flow is explained:

[0193] Step 401 is the same as step 301, and will not be described again.

[0194] Step 402: Select UE (i.e., read / write device) for AIoT function. The process of selecting UE for AIoT function is similar to the process of selecting RAN for AIoT function in step 302 of Figure 3 above, and will not be described in detail.

[0195] Step 403: The AIoT function sends a request message to the UE, the request message carrying a temporary identifier for security protection; and the request message also carrying a security protection command. Optionally, the request message may also carry a message authentication code for authenticating the network. Optionally, the request message may also carry one of the following: the previous temporary identifier, or the initial identifier of the AIoT device.

[0196] The difference between step 403 and step 303 is that the AIoT function can send a request message to the user device (UE) through other core network elements and access network devices. These other core network elements can include at least one of AMF (User Plane Function) and UPF (User Plane Function). The access network device can be represented as RAN (RAN), specifically, it can be a gNB (gNB), which can also be called an AIoT gNB or an AIoT enable gNB, etc., without limitation here.

[0197] The descriptions regarding the processing of AIoT function execution request messages and the content of the request messages are the same as those in the aforementioned embodiments and will not be repeated.

[0198] Step 404: The UE sends a request message to the AIoT device. The processing of the UE sending a request message to the AIoT device is similar to the processing of the RAN (read / write device) sending a request message to the AIoT device in the previous embodiment, the only difference being that the request message sent by the UE can be a sidechain message, which will not be described in detail here.

[0199] Step 405 is the same as step 305, and will not be described again.

[0200] Step 406: The AIoT device sends a response message to the AIoT function through the UE.

[0201] Step 406 differs from step 306 in that the AIoT device sending a response message to the AIoT function through the UE may include: the AIoT device sending a response message to the AIoT function through access network devices and other core network elements. Other related descriptions of this response message are the same as in the aforementioned embodiments and will not be repeated.

[0202] Step 407 is the same as step 307, and will not be described again.

[0203] The two processes illustrated in Figures 3 and 4 above are applicable to two AIoT topologies, respectively. Figure 3 is applicable to Topology 1, and Figure 4 is applicable to Topology 2. In Topology 1, the AIoT device is directly connected to the access network device (i.e., the RAN shown in Figure 3), which acts as a reader. In Topology 2, the device connects to the base station through a relay node (UE shown in Figure 4). For AIoT devices, the protocol stack consists of three layers: the PHY layer, the MAC (Medium Access Control) layer, and the AIoT specific NAS layer (or simply the AIoT NAS layer). The AIoT NAS layer is located between the AIoT device and the AIoTF and is used to transmit messages from the core network to the device. These messages can include the aforementioned request messages, response messages, etc.

[0204] In this implementation, a temporary identifier can be assigned through a request message in the command-only flow. This allows the temporary identifier of the AIoT device to be refreshed, avoiding the problems of the AIoT device being easily tracked and / or linked due to the long-term transmission of the same temporary identifier of the AIoT device over the air interface. Furthermore, since the temporary identifier is protected by security, it can be ensured that the updated temporary identifier is not eavesdropped on or tampered with, thereby ensuring the security of the AIoT device.

[0205] Furthermore, the request message can carry a security-protected command to trigger the AIoT device to perform one of the following operations: activation, deactivation, etc. This is particularly suitable for AIoT functions to directly send request messages containing commands to AIoT devices in the command flow, thereby shortening the interaction process between AIoT devices and AIoT functions; and because the command is security-protected, the security of the upper-layer data of the commands transmitted between AIoT functions and AIoT devices can be guaranteed.

[0206] Furthermore, the request message can carry a message authentication code for authenticating the network. This allows network authentication to be performed on the AIoT device side, ensuring the reliability of the messages received by the AIoT device and consequently guaranteeing the security of the data reported by the AIoT device.

[0207] Furthermore, the response message returned by the AIoT device to the AIoT function can also carry securely protected response data of the AIoT device and / or an authentication response for authenticating the AIoT device. In this way, because the command is securely protected, the security of the data transmitted by the AIoT device can be guaranteed, and the network side can also authenticate the AIoT device by verifying the authentication response, further ensuring the security of the data obtained by the network side.

[0208] In some possible implementations, the request message may be a message in the inventory and command flow.

[0209] The messages in the inventory and command flow can include inventory requests and command requests. In this embodiment, the request message can refer to a command request.

[0210] Figure 5 illustrates the communication method under the inventory and command flow as an example:

[0211] Step 501: The AIoT function sends an inventory request to the Reader (reading and writing device). The inventory request may carry one of the following: the previous temporary identifier (temporary ID_n as shown in Figure 5) or the initial identifier of the AIoT device.

[0212] Step 502: The Reader sends a paging request to the AIoT device. The paging request carries the inventory request (Figure 5 simply illustrates that the paging request carries a temporary ID_n).

[0213] Step 503: The AIoT device sends a paging response to the Reader, which carries one of the following: the previous temporary identifier (temporary ID_n as shown in Figure 5) or the initial identifier of the AIoT device.

[0214] Specifically, the AIoT device may execute step 503 if the paging request carries its previous temporary identifier or the initial identifier of the AIoT device.

[0215] Step 504: The Reader sends an inventory response (or a Report) to the AIoT function, which carries one of the following: the previous temporary identifier (temporary ID_n as shown in Figure 5) or the initial identifier of the AIoT device.

[0216] Optionally, after the AIoT device and network (such as a reader and / or AIoT functionality) perform an inventory process (e.g., after completing step 504), a connection is established between the network and the AIoT device (or the connection corresponding to the AIoT device). On the network side (or the network and AIoT device side), identification information related to this connection can be maintained. This connection-related identification information may include the AS (Access Layer) ID and / or the connection ID. In this case, the network maintains the connection-related identification information by associating and saving the AIoT device's previous temporary identifier (temporary ID_n as shown in Figure 5) or the AIoT device's initial identifier with the connection-related identification information.

[0217] Optionally, when an inventory process is performed between an AIoT device and a network (such as a reader and / or AIoT functionality) (e.g., after step 504 is completed), no connection is established between the network and the AIoT device.

[0218] Step 505: The AIoT function sends a command request (i.e., a request message) to the Reader. The command request carries a temporary identifier for security protection (shown as {temporary ID_n+1} in Figure 5). In addition, the command request may also carry a command to trigger the AIoT device to perform at least one of the following operations: activation, reading data, writing data, temporary deactivation, and permanent deactivation.

[0219] The explanation regarding the temporary identification for this security protection is the same as in the aforementioned embodiments and will not be repeated here.

[0220] The description of the command is the same as that in the previous embodiment. The difference is that the command in this embodiment may or may not be protected by security, and there is no limitation here. If the command is protected by security, the specific processing method for protecting the command is the same as step 303 in the previous embodiment, and will not be repeated.

[0221] Optionally, if no connection is established between the network and the AIoT device when the AIoT device performs an inventory process with the network (such as a reader and / or AIoT functionality) (e.g., after completing step 504), the command request may also carry one of the previous temporary identifier or the initial identifier of the AIoT device.

[0222] The explanations regarding whether the AIoT function should carry the previous temporary identifier or the initial identifier of the AIoT device in the command request, as well as the explanations regarding the previous temporary identifier and the initial identifier of the AIoT device, are the same as those in the aforementioned embodiments and will not be repeated.

[0223] Optionally, when an inventory process is performed between the AIoT device and the network (such as a reader and / or an AIoT function) (e.g., after completing step 504), and a connection corresponding to the AIoT device is established between the network and the AIoT device, the command request may not carry the previous temporary identifier or the initial identifier of the AIoT device. In this case, the AIoT function may send connection-related identification information to the reader in plaintext while sending the command request, or it may not send connection-related identification information; this is not limited here.

[0224] Step 506: The Reader sends a command request to the AIoT device. This command request is the same as that in step 505 and will not be described again.

[0225] Step 507: The AIoT device saves the temporary identifier. The security verification performed before the AIoT device saves this temporary identifier (i.e., the updated temporary identifier) ​​and the specific details of how the AIoT device saves this temporary identifier are the same as in the previous embodiments and will not be repeated here.

[0226] Here, the AIoT device can execute the corresponding operation of the command while, before, or after saving the temporary identifier. The relevant descriptions of the command and the operation of the AIoT device are the same as those in the previous embodiments. The difference from the previous embodiments is that the command in this embodiment may or may not be protected by security, which is not limited here; if the command is protected by security, the AIoT device performs the corresponding security verification on the command, which will not be repeated here.

[0227] Step 508: The AIoT device sends a command response (i.e., the response message in the aforementioned embodiments) to the Reader. This command response may carry at least one of the following: information indicating successful update of the temporary identifier (simply illustrated as ACK in Figure 5), the previous temporary identifier (temporary ID_n as illustrated in Figure 5), the current temporary identifier (which is also the temporary identifier updated this time), or the temporary identifier updated this time (temporary ID_n+1 as illustrated in Figure 5). Alternatively, the command response may also carry an encrypted permanent identifier of the AIoT device.

[0228] Optionally, the command response may also carry response data from the AIoT device. The content of this response data is the same as in the aforementioned embodiments and will not be repeated here. In this embodiment, the response data may or may not be protected by security. If security protection is implemented, the specific processing method for protecting the response data is the same as the relevant description in the aforementioned embodiments and will not be repeated here.

[0229] Step 509: The Reader sends a command response (i.e., the response message in the aforementioned embodiment) to the AIoT function. The content carried by the command response is the same as that in step 508, and will not be described again.

[0230] In this embodiment, during the inventory and command process, a temporary identifier with security protection can be assigned through a command request (i.e., a request message). This allows the identifier of the AIoT device to be refreshed, avoiding the problems of the AIoT device being easily tracked and / or linked due to the long-term transmission of the same AIoT device identifier over the air interface. Furthermore, since the temporary identifier is protected by security, it can be ensured that the updated identifier is not eavesdropped on or tampered with, thereby ensuring the security of the AIoT device.

[0231] In some possible implementations, the request message can be a message in the inventory process, such as a request message for inventory or an inventory request. The request message (i.e., the inventory request) may carry one of the following: the previous temporary identifier or the initial identifier of the AIoT device.

[0232] Figure 6 illustrates the communication method under the inventory process as an example:

[0233] Step 601: The AIoT function sends an inventory request to the Reader (reading and writing device). The inventory request may carry one of the following: the previous temporary identifier (temporary ID_n as shown in Figure 6) or the initial identifier of the AIoT device.

[0234] Regarding the AIoT function's specific instructions on whether to carry the previous temporary identifier or the initial identifier of the AIoT device in the inventory request, as well as the relevant instructions on the previous temporary identifier and the initial identifier of the AIoT device, they are the same as those in the aforementioned embodiments and will not be repeated.

[0235] For example, in this embodiment, the inventory request issued by the AIoT function may carry the temporary identifier from the previous execution. This temporary identifier may have been updated by the previous execution of the command-only process, such as by the previous execution of the process shown in Figure 3 (steps 303 to 306), or by the previous execution of the process shown in Figure 4 (steps 403 to 406); or, the temporary identifier may have been updated by the previous execution of the inventory and command process, such as by the previous execution of the process shown in Figure 5 (steps 505 to 509).

[0236] Step 602: The Reader sends a paging request to the AIoT device. The paging request carries the inventory request. Figure 6 simply illustrates that the paging request carries a temporary ID_n.

[0237] Step 603: The AIoT device sends a paging response to the Reader, which carries one of the following: the previous temporary identifier (temporary ID_n as shown in Figure 6) or the initial identifier of the AIoT device.

[0238] Specifically, the AIoT device may execute step 603 if the paging request carries its previous temporary identifier or the initial identifier of the AIoT device.

[0239] Step 604: The Reader sends an inventory response (or a Report) to the AIoT function, which carries the temporary identifier from the previous step (temporary ID_n as shown in Figure 6) or the initial identifier of the AIoT device.

[0240] In this implementation, during the inventory process, the AIoT device can be paged by carrying the previous temporary identifier in the inventory request (i.e., request message). In this way, the AIoT device and the AIoT function can use the most recently updated AIoT device identifier for inventory, avoiding the problems of AIoT devices being easily tracked and / or linked due to the long-term transmission of the same AIoT device identifier over the air interface.

[0241] By adopting the solution provided in this embodiment, a temporary identifier can be allocated through a request message. This allows the temporary identifier of the AIoT device to be refreshed, avoiding problems such as the AIoT device being easily tracked and / or linked due to the long-term transmission of the same AIoT device identifier over the air interface. Furthermore, since the temporary identifier is protected by security, it can be ensured that the updated temporary identifier is not eavesdropped on or tampered with, thereby ensuring the security of the AIoT device.

[0242] Figure 7 is a schematic diagram of the composition structure of an AIoT device according to an embodiment of this application, including:

[0243] The first communication unit 701 is configured to receive a request message from a read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0244] As shown in Figure 7, AIoT devices also include:

[0245] The first processing unit 702 is used to perform security verification on the temporary identifier of the security protection based on the security context of the AIoT device.

[0246] The request message also carries one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier.

[0247] The first communication unit is configured to send a response message to the AIoT function through the read / write device, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, or the initial identifier of the AIoT device.

[0248] The encrypted permanent identifier is obtained by encrypting the permanent identifier based on the shared key between the AIoT device and the AIoT function.

[0249] The request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activate or deactivate.

[0250] The first processing unit is configured to decrypt the security protection command based on the shared key between the AIoT device and the AIoT function; if the decryption is successful, the command is verified as successful.

[0251] The request message also carries a message authentication code for authenticating the network.

[0252] The first processing unit is used to calculate the message verification code; if the message verification code is the same as the message authentication code, the authentication network is determined to be successful.

[0253] The response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device.

[0254] The security protection response data is obtained by processing the response data based on the shared key between the AIoT device and the AIoT function.

[0255] Figure 8 is a schematic diagram of the composition structure of an AIoT function according to an embodiment of this application, including:

[0256] The second communication unit 801 is used to send a request message to the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device.

[0257] The temporary identifier for security protection is obtained based on the security context of the AIoT device and the temporary identifier.

[0258] The request message also carries one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier.

[0259] The second communication unit is configured to receive a response message sent by the AIoT device through the read / write device, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, or the initial identifier of the AIoT device.

[0260] The request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activate or deactivate.

[0261] The security protection command is obtained by encrypting the command based on the shared key between the AIoT device and the AIoT function.

[0262] The request message also carries a message authentication code for authenticating the network.

[0263] The response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device.

[0264] As shown in Figure 8, AIoT functionality also includes:

[0265] The second processing unit 802 is used to determine that the AIoT device has been successfully authenticated if the expected response is the same as the authentication response.

[0266] The second communication unit is used to send service type indication information to the read / write device, wherein the service type indication information is used to indicate the service type corresponding to the command.

[0267] Figure 9 is a schematic diagram of the composition structure of a read / write device according to an embodiment of this application, including:

[0268] The third communication unit 901 is configured to receive a request message from the AIoT function, wherein the request message carries a temporary identifier for the security protection of the AIoT device, the temporary identifier being used to update the identifier of the AIoT device; and to send the request message to the AIoT device.

[0269] The request message also carries one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier.

[0270] The third communication unit is used to send a response message from the AIoT device to the AIoT function, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, and the initial identifier of the AIoT device.

[0271] The request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activate or deactivate.

[0272] The request message also carries a message authentication code for authenticating the network.

[0273] The response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device.

[0274] The third communication unit is configured to receive service type indication information from the AIoT function, wherein the service type indication information is used to indicate the service type corresponding to the command.

[0275] The device in this application embodiment can realize the corresponding functions of the various devices in the foregoing communication method embodiments. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in this device can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the device of this application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0276] Figure 10 is a schematic structural diagram of a communication device 1000 according to an embodiment of this application. The communication device 1000 includes a processor 1010, which can call and run computer programs from a memory to enable the communication device 1000 to implement the methods in the embodiments of this application. In one possible implementation, the communication device 1000 may further include a memory 1020. The processor 1010 can call and run computer programs from the memory 1020 to enable the communication device 1000 to implement the methods in the embodiments of this application. The memory 1020 may be a separate device independent of the processor 1010, or it may be integrated into the processor 1010. In one possible implementation, the communication device 1000 may further include a transceiver 1030, which the processor 1010 can control to communicate with other devices. Specifically, it can send information or data to other devices, or receive information or data sent by other devices. The transceiver 1030 may include a transmitter and a receiver. The transceiver 1030 may further include antennas, and the number of antennas may be one or more.

[0277] In one possible implementation, the communication device 1000 may be an AIoT device, an AIoT function, or a read / write device according to the embodiments of this application, and the communication device 1000 may implement the corresponding processes implemented by the AIoT device, the AIoT function, or the read / write device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0278] Figure 11 is a schematic structural diagram of a chip 1100 according to an embodiment of this application. The chip 1100 includes a processor 1110, which can call and run computer programs from memory to implement the methods in the embodiments of this application. In one possible implementation, the chip 1100 may further include a memory 1120. The processor 1110 can call and run computer programs from the memory 1120 to implement the methods executed by an AIoT device, AIoT function, or read / write device in the embodiments of this application. The memory 1120 may be a separate device independent of the processor 1110, or it may be integrated into the processor 1110. In one possible implementation, the chip 1100 may further include an input interface 1130. The processor 1110 can control the input interface 1130 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips. In one possible implementation, the chip 1100 may further include an output interface 1140. The processor 1110 can control the output interface 1140 to communicate with other devices or chips, specifically, it can output information or data to other devices or chips.

[0279] In one possible implementation, the chip can be applied to the AIoT device, AIoT function, or read / write device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the AIoT device, AIoT function, or read / write device in the various methods of the embodiments of this application. For simplicity, these will not be elaborated further here. It should be understood that the chip mentioned in the embodiments of this application can also be called a system-on-a-chip, system-on-a-chip, chip system, or system-on-chip, etc. The processor mentioned above can be a general-purpose processor, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other programmable logic device, transistor logic device, discrete hardware component, etc. Among them, the general-purpose processor mentioned above can be a microprocessor or any conventional processor, etc. The memory mentioned above can be volatile memory or non-volatile memory, or can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM). It should be understood that the above-described memory is exemplary but not limiting. For example, the memory in the embodiments of this application can also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. In other words, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0280] This application also provides a communication system. The communication system includes an AIoT device, an AIoT function, and a read / write device. The AIoT device is used to implement the corresponding functions implemented by the AIoT device in the above-described method; the AIoT function is used to implement the corresponding functions implemented by the AIoT function in the above-described method; and the read / write device is used to implement the corresponding functions implemented by the AIoT device in the above-described method.

[0281] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0282] It should be understood that the sequence number of each process in the various embodiments of this application does not imply the order of execution; the execution order of each process should be determined by its function and internal logic. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. The above descriptions are merely specific embodiments of this application, and the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

A communication method performed by an environmental Internet of Things (AIoT) device, comprising: Receive a request message from a read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device. The method according to claim 1 further includes: The temporary identifier for security protection is verified based on the security context of the AIoT device. The method according to claim 1 or 2, wherein, The request message also carries one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier. The method according to any one of claims 1-3 further comprises: The read / write device sends a response message to the AIoT function, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, or the initial identifier of the AIoT device. The method according to claim 4, wherein, The encrypted permanent identifier is obtained by encrypting the permanent identifier based on the shared key between the AIoT device and the AIoT function. The method according to claim 4 or 5, wherein, The request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activate or deactivate. The method according to claim 6 further includes: The security protection command is decrypted based on the shared key between the AIoT device and the AIoT function; If decryption is successful, the command is verified successfully. The method according to claim 6 or 7, wherein, The request message also carries a message authentication code for authenticating the network. The method according to claim 8 further includes: Calculate the message verification code; If the message verification code is the same as the message authentication code, the authentication network is considered successful. The method according to any one of claims 6-9, wherein, The response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device. The method according to claim 10, wherein, The security protection response data is obtained by processing the response data based on the shared key between the AIoT device and the AIoT function. A communication method performed by an AIoT function, comprising: A request message is sent to the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device. The method according to claim 12, wherein, The temporary identifier for security protection is obtained based on the security context of the AIoT device and the temporary identifier. The method according to claim 12 or 13, wherein, The request message also carries one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier. The method according to any one of claims 12-14 further comprises: The system receives a response message from the AIoT device via the read / write device, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, or the initial identifier of the AIoT device. The method according to claim 15, wherein, The request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activate or deactivate. The method according to claim 16, wherein, The security protection command is obtained by encrypting the command based on the shared key between the AIoT device and the AIoT function. The method according to claim 16 or 17, wherein, The request message also carries a message authentication code for authenticating the network. The method according to any one of claims 16-18, wherein, The response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device. The method according to claim 19 further includes: If the expected response is the same as the authentication response, the authentication of the AIoT device is determined to be successful. The method according to any one of claims 16-20 further comprises: Send service type indication information to the read / write device, wherein the service type indication information is used to indicate the service type corresponding to the command. A communication method performed by a read / write device, comprising: Receive a request message from the AIoT function, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device; Send the request message to the AIoT device. The method according to claim 22, wherein, The request message also carries one of the following: the previous temporary identifier, the initial identifier of the AIoT device, wherein the initial identifier includes an initial temporary identifier or a permanent identifier. The method according to claim 22 or 23 further includes: A response message from the AIoT device is sent to the AIoT function, wherein the response message carries at least one of the following: information indicating successful update of the temporary identifier, the temporary identifier of the AIoT device, the encrypted permanent identifier of the AIoT device, or the initial identifier of the AIoT device. The method according to claim 24, wherein, The request message also carries a security protection command, which is used to trigger the AIoT device to perform one of the following operations: activate or deactivate. The method according to claim 25, wherein, The request message also carries a message authentication code for authenticating the network. The method according to claim 25 or 26, wherein, The response message also carries at least one of the following: an authentication response for authenticating the AIoT device, and security protection response data for the AIoT device, wherein the response data includes one of the following: an activation confirmation response for the AIoT device, and a deactivation confirmation response for the AIoT device. The method according to any one of claims 25-27 further comprises: Receive service type indication information from the AIoT function, wherein the service type indication information is used to indicate the service type corresponding to the command. An AIoT device includes: The first communication unit is configured to receive a request message from a read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device. An AIoT function includes: The second communication unit is used to send a request message to the read / write device, wherein the request message carries a temporary identifier for the security protection of the AIoT device, and the temporary identifier is used to update the identifier of the AIoT device. A read / write device, comprising: The third communication unit is configured to receive a request message from the AIoT function, wherein the request message carries a temporary identifier for the security protection of the AIoT device, the temporary identifier being used to update the identifier of the AIoT device; and to send the request message to the AIoT device. An AIoT device includes: A transceiver, a processor, and a memory for storing a computer program, the transceiver for communicating with other devices, and the processor for calling and running the computer program stored in the memory to cause the AIoT device to perform the method as described in any one of claims 1 to 11. An AIoT function includes: A transceiver, a processor, and a memory for storing a computer program, the transceiver for communicating with other devices, and the processor for calling and running the computer program stored in the memory to cause the AIoT function to perform the method as described in any one of claims 12 to 21. A read / write device, comprising: A transceiver, a processor, and a memory for storing a computer program, the transceiver for communicating with other devices, and the processor for calling and running the computer program stored in the memory to cause the read / write device to perform the method as described in any one of claims 22 to 28. A chip, comprising: A processor for retrieving and running a computer program from memory, causing a device having the chip mounted to perform the method as described in any one of claims 1 to 11, or claims 12 to 21, or claims 22 to 28. A computer-readable storage medium for storing a computer program that, when run by a device, causes the device to perform the method as described in any one of claims 1 to 11, or claims 12 to 21, or claims 22 to 28. A computer program product includes computer program instructions that cause a computer to perform the method as described in any one of claims 1 to 11, or claims 12 to 21, or claims 22 to 28. A computer program that causes a computer to perform the method as described in any one of claims 1 to 11, or claims 12 to 21, or claims 22 to 28.

Images