Communication method and device

Abstract

The present application relates to a communication method and a device. The method comprises: sending a first request message to an AIoT device, wherein the first request message carries a first identifier of the AIoT device; receiving a first response message from the AIoT device; when the first response message is abnormal, sending indication information to the AIoT device, wherein the indication information is used for triggering re-access of the AIoT device; and receiving a re-access message from the AIoT device, wherein the re-access message carries a second 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-enabled IoT (AIoT) devices interact with AIoT functional entities through their corresponding readers or readers / writers. In this scenario, the AIoT functional entity typically pages the AIoT device through the reader / writer. When responding to the page, the AIoT device includes an identifier in its response so that the network side (such as the reader / writer) can confirm that the AIoT device has been successfully paged. However, even when the AIoT device has confirmed that it has been paged and has responded, the response received by the network side may be abnormal due to various reasons. In this case, the network side will consider that the AIoT device has not been paged or that the page failed, and may subsequently re-initiate a page for the AIoT device, thereby reducing paging efficiency. Summary of the Invention

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

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

[0005] Send a first request message to the AIoT device, wherein the first request message carries a first identifier of the AIoT device;

[0006] Receive the first response message from the AIoT device;

[0007] When the first response message is abnormal, an indication message is sent to the AIoT device, wherein the indication message is used to trigger the AIoT device to reconnect;

[0008] Receive a re-access message from the AIoT device, wherein the re-access message carries a second identifier of the AIoT device.

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

[0010] Receive indication information, wherein the indication information is used to trigger the AIoT device to reconnect;

[0011] Send a re-access message, wherein the re-access message carries a second identifier of the AIoT device.

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

[0013] A first communication unit is configured to send a first request message to an AIoT device, wherein the first request message carries a first identifier of the AIoT device; receive a first response message from the AIoT device; when the first response message is abnormal, send indication information to the AIoT device, wherein the indication information is used to trigger the AIoT device to re-access; and receive a re-access message from the AIoT device, wherein the re-access message carries a second identifier of the AIoT device.

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

[0015] The second communication unit is used to receive indication information, wherein the indication information is used to trigger the AIoT device to re-access; and to send a re-access message, wherein the re-access message carries the second identifier of the AIoT device.

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

[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 a chip for implementing the above method.

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

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

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

[0022] By adopting the above scheme, when the response message from the AIoT device is abnormal, the read / write device triggers the AIoT device to re-access, and the AIoT device retransmits its identifier during re-access. In this way, even if the AIoT device is paged but the response message received by the read / write device is abnormal, the read / write device can trigger the AIoT device to retransmit its identifier for re-access. This avoids the problem of reduced paging efficiency caused by the network side considering the AIoT device a paging failure and re-paged the AIoT device when the response message is abnormal. Attached Figure Description

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

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

[0025] Figures 3 and 4 are various flowchart examples of a communication method according to an embodiment of this application.

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

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

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

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

[0030] The technical solutions of this application embodiment can be applied to various communication systems, such as NR, NR evolution, WLAN, WiFi, 6G, or other communication systems.

[0031] This application describes various embodiments in conjunction with network devices and terminals. A terminal is a device with data collection capabilities, which can be mobile or fixed, and may also be referred to as a mobile station, user unit, etc. A terminal can be a station in a WLAN, or a smart terminal, wireless modem, laptop, tablet, etc. In this application's embodiments, the terminal can be a VR / AR 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's embodiments, the terminal can also be a wearable device.

[0032] 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 base station in LTE, a relay station, a network device (gNB) in a vehicle-mounted device, wearable device, or NR network, or a network device in a future PLMN network, or a network device in a non-terrestrial network, etc. As an example and not a limitation, in this embodiment, the network device can have mobility characteristics; for example, the network device can be a mobile device.

[0033] In this embodiment, the network device may include at least one of the following: a 6G system architecture 6G Radio Access Network (RAN) and a 6G Core Network Function (CN NF). Under the 6G system architecture, independent distributed NAS termination can be supported between user equipment (UE) and its corresponding 6G network function. That is, each function within a 6G user equipment can directly transmit signals with the appropriate network function (NF) without going through a single termination point. Therefore, the 6G Radio Access Network (RAN) and the 6G Core Network Function (CN NF) can communicate directly with each other.

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

[0035] Figure 1 exemplarily illustrates a communication system 100. The communication system includes network devices 110 and terminals 90. In one possible implementation, the communication system 100 may include multiple network devices 110, and each network device 110 may include at least one terminal 90 within its coverage area; 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 communication system may also include multiple core networks for communicating with access network devices. Access network devices may be base stations of LTE, LTE-A, or NR systems, or 6G radio access networks (RANs). 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.

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

[0037] The read / write device executes S210 to send a first request message to the AIoT device, wherein the first request message carries the first identifier of the AIoT device.

[0038] The read / write device executes S220, receiving a first response message from the AIoT device.

[0039] When the first response message is abnormal, the read / write device executes S230 and sends an indication message to the AIoT device, wherein the indication message is used to trigger the AIoT device to re-access.

[0040] S240 is executed on the AIoT device side to receive indication information, wherein the indication information is used to trigger the AIoT device to re-access.

[0041] S250 is executed on the AIoT device side to send a re-access message, wherein the re-access message carries the second identifier of the AIoT device.

[0042] The read / write device executes S260 to receive a re-access message from the AIoT device, wherein the re-access message carries a second identifier of the AIoT device.

[0043] Reading and writing devices may include terminals and / or access network devices.

[0044] In some possible implementations, with reference to Figure 3, one implementation flow of the communication method provided in this application is described:

[0045] Step 301: The AF sends a service request to the AIoT functional entity. This service request may be sent directly by the AF to the AIoT functional entity, or it may be forwarded by the AF to the AIoT functional entity through NEF; this is not limited here.

[0046] In this embodiment, the business request can be an inventory request message or a command request message from the Application Function (AF).

[0047] Business requests may carry information about AIoT devices, which may include the permanent identifier and / or temporary identifier of the AIoT device, without limitation here.

[0048] In actual processing, business requests can also carry other information, such as business type indication, group identification information, number of devices, group sending (indication), single sending (indication), etc., at least one of these.

[0049] The business type indicator can be used to indicate any one of the following: inventory only, inventory and command, or command only.

[0050] Group identification information includes at least one of the following corresponding to the group: bit mask, filtering information, etc.

[0051] The purpose of the bit mask is to page or identify a group of AIoT devices. The specific composition of the bit mask is not limited in this embodiment. For example, the bit mask may include multiple bits, some of which are composed of the same bits in the identifier of the AIoT devices in the group, and the remaining bits in the bit mask may be set to zero.

[0052] The filtering information can be relevant conditions used to page a group of AIoT devices. For example, the filtering information can include conditions for paged a group of AIoT devices consisting of at least one of the following: a specified operator, a specified geographical area, or a specified service type (such as inventory service, wake-up service, etc.).

[0053] This is merely an illustrative example of what a business request might carry, and does not limit or exhaustively list the possible contents of a business request issued by AF.

[0054] Step 302: The AIoT functional entity sends a first identifier of the AIoT device; correspondingly, the read / write device receives the first identifier from the AIoT functional entity. Specifically, the AIoT functional entity sends a second request message to the read / write device; correspondingly, the read / write device receives the second request message, wherein the second request message carries the first identifier. The first identifier includes at least a portion of a permanent identifier and at least a portion of a temporary identifier.

[0055] Optionally, the first identifier may include a permanent identifier or a temporary identifier. In this case, the first identifier is all of the permanent identifiers or all of the temporary identifiers. This embodiment does not limit how the AIoT functional entity specifically obtains the temporary identifier.

[0056] Optionally, the first identifier may include a portion of a permanent identifier (or a partially permanent identifier) ​​or a portion of a temporary identifier (or a partially temporary identifier). This approach can reduce the signaling overhead of subsequent paging; it can be applied to paging individual AIoT devices or to paging groups of devices.

[0057] In one scenario, when paging group devices, the first identifier can be a portion of the same bits in the permanent identifiers of multiple AIoT devices in the group, or a portion of the same bits in the temporary identifiers of multiple AIoT devices in the group.

[0058] In one scenario, when paging a single AIoT device, the first identifier may be a portion of the permanent identifier of the single AIoT device, or a portion of the permanent identifier of the single AIoT device. In this case, this embodiment does not limit which bits(s) of the permanent or temporary identifier the first identifier is, or the length of that portion of bits.

[0059] For example, the first identifier includes a portion of bits from the permanent identifier of the individual AIoT device. These bits may be the underlying identifier of the AIoT device included in the permanent identifier, or they may include the underlying identifier of the AIoT device within the permanent identifier. This underlying identifier may include an EPC (Electronic Product Code), etc. This is merely an illustrative example and does not limit which specific bits or their length within the permanent or temporary identifier the first identifier represents.

[0060] The second request message can be an inventory request message or a command request message.

[0061] For example, if the AIoT functional entity is performing only inventory check business this time, then the second request message is the inventory check request message in the only inventory check business process.

[0062] For example, if the AIoT functional entity performs inventory and command services this time, the second request message is the inventory request message in the inventory and command service process.

[0063] For example, if the AIoT functional entity is performing a command-only service this time, the second request message is a command request message in the command-only process. Optionally, the command request message may also carry a command, which may include one or more of the following: read command, write command, activation command, temporary deactivation command, permanent deactivation command, etc.

[0064] It should also be noted that, in addition to the content or parameters mentioned above, the second request message may also carry other content or parameters, such as a Correlation ID (business association indicator), etc.

[0065] In one approach, the AIoT functional entity triggers step 302 based on a business request from the AF.

[0066] In another approach, step 301 may not be executed, and step 302 may be triggered by the AIoT functional entity based on local policies, rules, or protocols. For example, the policy, rule, or protocol may include the AIoT functional entity needing to periodically inventory AIoT devices, and / or the AIoT functional entity needing to periodically read data, write data, or activate or temporarily deactivate AIoT devices, etc. The length of the period can be specified in the policy, rule, or protocol, and is not limited here.

[0067] Step 303: The read / write device sends a response to the AIoT functional entity.

[0068] Optionally, if the second request message is an inventory request message, then the response is an inventory response, wherein the inventory response may indicate at least one of the following: the read / write device has successfully received the inventory request message, or the read / write device will execute the corresponding business operation. Specifically, after receiving the inventory request message, the read / write device determines that it can initiate an inventory; the read / write device sends an inventory response to the AIoT functional entity.

[0069] Optionally, if the second request message is a command request message, then the response is a command response, wherein the command response may indicate at least one of the following: the read / write device has successfully received the command request message, or the read / write device will perform a corresponding business operation. Specifically, after receiving the command request message, the read / write device determines that it can execute the command process or procedure; the read / write device sends a command response to the AIoT functional entity.

[0070] Step 304: The read / write device pre-stores the first identifier of the AIoT device. Specifically, the read / write device reads the first identifier of the AIoT device from the second request message and pre-stores or saves it locally.

[0071] Step 305: The read / write device sends a first request message to the AIoT device, wherein the first request message carries a first identifier of the AIoT device. Correspondingly, the AIoT device receives the first request message. This first request message may be carried by a paging message.

[0072] After receiving the first request message (or a paging message carrying the first request message), if the AIoT device verifies or determines that the first identifier matches its own identifier, it determines that it has successfully paged itself, i.e., the AIoT device has been successfully paged, and then executes step 306 and subsequent processing. Alternatively, if the AIoT device verifies or determines that the first identifier does not match its own identifier, it determines that it is not paged itself, and subsequent processing is not required.

[0073] In the process of an AIoT device verifying or determining whether the first identifier matches or does not match its own identifier, the following situations may occur:

[0074] In one scenario, the first identifier may include all of the permanent identifier or all of the temporary identifier.

[0075] If the first identifier is the same as its own permanent identifier or temporary identifier, the AIoT device determines or verifies that the first identifier matches its own identifier; and / or, if the first identifier is different from both its own permanent identifier and temporary identifier, the AIoT device determines or verifies that the first identifier does not match its own identifier.

[0076] In another case, the first identifier may include a portion of a permanent identifier or a portion of a temporary identifier.

[0077] If an AIoT device's permanent identifier includes the first identifier, or its temporary identifier includes the first identifier, the device determines or verifies that the first identifier matches its own identifier; and / or, if neither its permanent identifier nor its temporary identifier includes the first identifier, the device determines or verifies that the first identifier does not match its own identifier.

[0078] Step 306: The AIoT device sends a random access preamble.

[0079] Step 307: The reading and writing device replies with a Random Access Response.

[0080] Steps 306 and 307 involve the exchange of msg1 (random access preamble) and msg2 (random access response) between the AIoT device and the read / write device during the random access process. The specific content of msg1 and msg2 exchanged between the AIoT device and the read / write device, as well as the related processing, are not limited here.

[0081] Steps 306 and 307 can be optional.

[0082] Step 308: The AIoT device sends a first response message, wherein the first response message carries the second identifier. Specifically, the AIoT device sends a first response message corresponding to the first request message to the read / write device; correspondingly, the read / write device receives the first response message from the AIoT device.

[0083] The first response message can be carried by the paging response message.

[0084] For example, if an AIoT device performs a four-step random access process, then after performing steps 306 to 307, step 308 is performed. The paging response message in step 308 can be transmitted as the payload of msg3 in the four-step random access process, or the paging response message can be carried by msg3.

[0085] For example, if the AIoT device performs a two-step random access procedure, steps 306 and 307 can be skipped, and step 308 can be executed directly. The paging response message in step 308 can be transmitted as the payload of msgA in the two-step random access procedure, or the paging response message can be carried by msgA. For instance, msgA can carry a random access preamble and the paging response message. Or, for another example, msgA can carry a random access preamble and msg3, and the paging response message can be transmitted as the payload of msg3, or the paging response message can be carried by msg3.

[0086] Here, when the AIoT device normally sends a first response message, the first response message should carry a second identifier. This second identifier includes at least a portion of a permanent identifier, at least a portion of a temporary identifier, or an underlying identifier. The second identifier of the AIoT device can refer to the correct identification information of the AIoT device. In the following text, the correct identification information and the second identifier have the same meaning and will not be explained again. That is, the first response message that the AIoT device should send will carry the correct identification information of the AIoT device, which can be at least a portion of a permanent identifier, at least a portion of a temporary identifier, or an underlying identifier.

[0087] There are several ways in which AIoT devices can determine the specific type and content of the second identifier:

[0088] In one approach, the second identifier is the same as the first identifier received by the AIoT device, or the second identifier contains the first identifier, or the second identifier is an underlying identifier. In this case, there is no restriction on which identifier the AIoT device will use as the second identifier; the AIoT device itself can randomly select which identifier to use as the second identifier.

[0089] For example, an AIoT device can use an identifier that is the same as the first identifier as the second identifier. For instance, if the first identifier is part of a permanent identifier, the second identifier is also the part of a permanent identifier that is the same as the first identifier; or if the first identifier is all of a temporary identifier, the second identifier is also all of a temporary identifier that is the same as the first identifier. Here, we do not limit or exhaust all possible cases.

[0090] For example, when the first identifier is a part of a permanent identifier or a part of a temporary identifier, the AIoT device can use an identifier containing the first identifier as the second identifier, or use the first identifier as the second identifier. For example, when the first identifier is a part of a permanent identifier, the second identifier is the same part of the permanent identifier as the first identifier, or the second identifier can be the entirety of the permanent identifier; for example, when the first identifier is a part of a temporary identifier, the second identifier is the same part of the temporary identifier as the first identifier, or the second identifier is the entirety of the temporary identifier. Here, we do not limit or exhaust all possible cases.

[0091] For example, regardless of the first identifier, an AIoT device can use the underlying identifier as the second identifier.

[0092] Alternatively, the AIoT device can pre-configure rules or policies related to the identifiers it feeds back. The AIoT device then needs to determine which identifier to use as the second identifier based on these rules or policies. For example, the AIoT device can determine whether to use an identifier that is the same as the first identifier, an identifier that contains the first identifier, or an underlying identifier as the second identifier.

[0093] Optionally, if the first request message is an inventory request message, the first response message is an inventory response message.

[0094] Optionally, if the first request message is a command request message, the first response message is a command response message.

[0095] It should be noted that when the first request message is a command request message, the command request message may also carry a command; correspondingly, when the AIoT device normally sends a command response message, in addition to carrying a second identifier, the command response message may or may not carry response data for the command, depending on actual regulations (such as protocol regulations). For example, when the command is a read command, the command response data includes the data that the AIoT device needs to report after executing the read command; for example, when the command is at least one of a write command, activation command, temporary deactivation command, or permanent deactivation command, the command response data may or may not be carried according to protocol regulations, which is not limited here.

[0096] The solutions provided in this application are mainly aimed at the following abnormal or erroneous situations: When an AIoT device sends a first response message, due to its own reasons, only part of the second identifier (i.e., correct identifier information) in the first response message is sent, that is, the complete second identifier of the AIoT device is not successfully sent; and / or, the AIoT device correctly sends the first response message, but the correct identifier information (second identifier) ​​in the first response message is tampered with, resulting in errors in the data or identifier read by the reading and writing device from the first response message when the first response message is received.

[0097] Step 309, the read / write device responds with a contention resolution message. Specifically, the read / write device responds with a contention resolution message to the AIoT device. The specific processing method used by the read / write device in this step is not limited here.

[0098] After completing step 309, the read / write device determines whether the first response message sent by the AIoT device is abnormal.

[0099] The processing by the read / write device further includes at least one of the following: determining that the first response message is abnormal when the first response message does not contain the first identifier; determining that the first response message is abnormal when the first response message does not contain the underlying identifier of the AIoT device. The underlying identifier is pre-stored by the read / write device.

[0100] In addition, the processing of the read / write device also includes: when the first response message contains a first identifier or an underlying identifier, determining that the first response message is normal.

[0101] As shown in Figure 3, the read / write device can execute step 310, which determines whether the received first response message contains a locally stored identifier. If it does not contain the identifier, the first response message is determined to be abnormal, and then step 311 is executed.

[0102] This embodiment proposes a handling mechanism for the following error: the identification information of the AIoT device received by the reading and writing device (i.e., the identifier carried in the first response message) is inconsistent with the identifier pre-stored on the reading and writing device side. The reading and writing device knows that it will only send a first response message if the AIoT device is successfully paged, and correspondingly, it will only receive the first response message sent by the AIoT device. Therefore, if the reading and writing device determines in step 310 that the first response message of the AIoT device is incorrect or abnormal, it can determine that the first response message sent by the AIoT device is erroneous or abnormal, and the reading and writing device decides to execute step 311.

[0103] Additionally, it may include: if the first response message contains a locally stored identifier, the read / write device determines that the first response message is normal, and the read / write device can execute step 315.

[0104] The identifiers pre-stored locally by the read / write device include: the identifier information of the AIoT device pre-stored by the read / write device; additionally, the identifiers pre-stored locally by the read / write device may also include the identifier information of one or more other AIoT devices pre-stored by the read / write device. Taking the identifier information of the AIoT device pre-stored by the read / write device as an example, the AIoT device identifier information pre-stored by the read / write device includes: the first identifier of the AIoT device pre-stored by the read / write device in step 304 (i.e., at least a part of the permanent identifier or at least a part of the temporary identifier), and / or the underlying identifier of the AIoT device pre-stored locally by the read / write device. This embodiment does not limit how the read / write device specifically obtains and / or pre-stores the underlying identifier.

[0105] The following example illustrates how a read / write device determines whether the received first response message contains a locally stored identifier:

[0106] In one example, the read / write device compares or determines whether the first response message contains a locally pre-stored first identifier (i.e., at least a part of a permanent identifier or at least a part of a temporary identifier) ​​and / or a locally pre-stored underlying identifier; if the first response message does not contain a locally pre-stored first identifier (i.e., at least a part of a permanent identifier or at least a part of a temporary identifier) ​​and the first response message does not contain a locally pre-stored underlying identifier, the read / write device determines that the first response message is abnormal.

[0107] Additionally, it may include: if the read / write device determines that the first response message is normal if the first response message contains a locally pre-stored first identifier or an underlying identifier.

[0108] This example is particularly applicable to situations where there is no restriction on which identifier the AIoT device side will use as the second identifier.

[0109] It should be noted that the reading and writing device can perform the processing of determining whether the first response message contains the locally pre-stored first identifier and the processing of determining whether the first response message contains the locally pre-stored underlying identifier sequentially or simultaneously.

[0110] For example, the read / write device first determines whether the first response message contains any locally pre-stored first identifier. If the first response message contains any locally pre-stored first identifier, it is determined that the first response message is normal. If the first response message does not contain any locally pre-stored first identifier, the read / write device determines whether the first response message contains any locally pre-stored underlying identifier. If the first response message contains one of the locally pre-stored underlying identifiers, it is determined that the first response message is normal. If the first response message does not contain any locally pre-stored underlying identifiers, it is determined that the first response message is abnormal. The above is only an illustrative example. In actual processing, it is also possible to first determine whether the first response message contains locally pre-stored underlying identifiers, and if not, then determine whether the first response message contains locally pre-stored first identifiers. This will not be elaborated here.

[0111] For another example, the read / write device simultaneously determines whether the first response message contains any locally pre-stored first identifier and any locally pre-stored underlying identifier; if the first response message contains any locally pre-stored underlying identifier or any of the first identifiers are the same, then the first response message is determined to be normal; if the first response message does not contain any locally pre-stored first identifier and does not contain any underlying identifier, then the first response message is determined to be abnormal.

[0112] In another example, the AIoT device can pre-configure rules or policies related to the identifiers it provides. The AIoT device needs to determine which identifier to use as the second identifier based on these rules or policies. In this example, the read / write device can also pre-configure rules that match or correspond to the AIoT device. For example, the read / write device can pre-configure rules or policies related to identifier matching, which can specify which identifier to compare or match the received data with.

[0113] In one scenario, the relevant rules or strategies on the AIoT device side are to use the received first identifier (i.e., at least a part of a permanent identifier or at least a part of a temporary identifier) ​​as the second identifier, or to use an identifier containing the first identifier as the second identifier; the read / write device side determines, based on the relevant rules or strategies for identifier matching, to compare or match the received first response message with the pre-stored first identifier.

[0114] In this case, the read / write device determines whether the first response message contains a locally pre-stored first identifier (i.e., at least a part of a permanent identifier or at least a part of a temporary identifier); if the first response message does not contain a locally pre-stored first identifier, the read / write device determines that the first response message is abnormal.

[0115] Additionally, it may include: if the read / write device determines that the first response message is normal if the first response message contains any of the locally pre-stored first identifiers.

[0116] In one scenario, the relevant rules or strategies on the AIoT device side use the underlying identifier as the second identifier; the reading / writing device side determines, based on the relevant rules or strategies for identifier matching, to compare or match the data carried in the received first response message with the pre-stored underlying identifier.

[0117] In this situation, the read / write device determines whether the first response message contains a locally pre-stored underlying identifier; if the first response message does not contain a locally pre-stored underlying identifier, it determines that the first response is not abnormal.

[0118] Additionally, it includes: if the read / write device determines that the first response message is normal when the first response message contains a locally pre-stored underlying identifier.

[0119] Step 311: The read / write device sends an indication message, which is carried by a NACK (non-acknowledgment (message) or denial response (message)).

[0120] Specifically, the read / write device sends the indication information by sending a NACK carrying the indication information to the AIoT device. Correspondingly, the AIoT device receives the indication information by receiving the NACK carrying the indication information sent by the read / write device.

[0121] The indication information is a flag bit or an indicator with a first value. This indication information can also be called retransmission indication information or retransmission indication.

[0122] Optionally, the indication information is a flag bit. This flag bit can also be called a retransmission flag bit. The specific content of this flag bit is not limited in this embodiment. As long as this flag bit is carried in the NACK, it is used to instruct the AIoT device to retransmit the identifier and / or trigger the AIoT device to re-access.

[0123] For example, the flag bit can be a code of a specified length, which can be configured according to the actual situation, such as 1 bit or more bits. There is no limitation here. As long as the reading and writing device and the AIoT device can parse or understand the meaning of the flag bit, it is within the protection scope of this embodiment.

[0124] Optionally, the indication information is an indicator that takes the first value. This indicator can also be called a retransmission indicator.

[0125] The length of this indicator can be configured according to the actual situation, for example, it can be 1 bit. The first value can also be configured according to the actual situation, for example, the length of this indicator is 1 bit, and the first value can be 1 or 0.

[0126] Additionally, if the indicator takes the second value, it can be used to indicate that the AIoT device does not need to retransmit the identifier. This second value is different from the first value. For example, the indicator may be 1 bit long, with the first value being 1 and the second value being 0, or vice versa.

[0127] In this scenario, regardless of whether the reading / writing device needs the AIoT device to retransmit the identifier and / or trigger the AIoT device to re-access, the indicator is carried in the NACK. The different values ​​of the indicator enable the AIoT device to determine whether to retransmit the identifier and / or re-access.

[0128] Step 312: The AIoT device determines whether to retransmit the identifier. If it needs to retransmit the identifier, then proceed to step 313.

[0129] Optionally, the indication information is a flag bit.

[0130] The AIoT device determines whether the received NACK carries a flag bit. If it does, it determines that a re-access attempt is needed and that the flag needs to be retransmitted. Alternatively, if the received NACK does not carry a flag bit, it determines that a re-access attempt is not needed and that the flag does not need to be retransmitted.

[0131] Optionally, the indication information is an indicator that takes the first value.

[0132] The AIoT device determines whether the received NACK carries an indicator. If it does, it checks whether the indicator value is the first value. If the indicator value is the first value, it determines that a re-access operation needs to be performed and that the identifier needs to be retransmitted. Alternatively, it may include: if the received NACK does not carry an indicator, or the indicator value is the second value, it determines that a re-access operation is not required and that the identifier does not need to be retransmitted.

[0133] This embodiment does not limit the subsequent processing for AIoT devices that determine that they do not need to retransmit the identifier.

[0134] Step 313: The AIoT device sends a re-access message, which carries the AIoT device's second identifier (i.e., correct identification information). Specifically, the AIoT device sends the re-access message to the read / write device; correspondingly, the read / write device receives the re-access message from the AIoT device.

[0135] The descriptions of the second identifier, and the methods by which the AIoT device determines the specific type and content of the second identifier, are the same as those in the aforementioned embodiments and will not be repeated.

[0136] This re-access message can also be called a resent first response message, or a retransmitted first response message, etc., without limitation or exhaustive list here.

[0137] Optionally, if the first request message is an inventory request message, the re-access message can be an inventory re-access message or a resent inventory response message.

[0138] Optionally, if the first request message is a command request message, the re-access message can be a command re-access message or a retransmitted command response message.

[0139] It should be noted that when the first request message is a command request message, the command request message may also carry a command. In this case, when the AIoT device sends a re-access message, the re-access message may or may not carry response data for the command, in addition to carrying the second identifier.

[0140] For example, when the command is a read command, the reconnection message can also carry the command response data, which may include the data that the AIoT device needs to report after executing the read command.

[0141] For example, when the command is at least one of the following: write command, activation command, temporary deactivation command, or permanent deactivation command, the reconnection message may or may not carry the command response data; this is not limited here.

[0142] The processing after the read / write device receives the re-access message includes: when the second identifier matches the first identifier of the AIoT device or the underlying identifier of the AIoT device, the read / write device sends a second response message, wherein the second response message carries the first identifier or the underlying identifier. The specific processing performed by the read / write device may include the following steps 314 to 315:

[0143] Step 314: The reading and writing device compares the second identifier carried in the received re-access message with the locally stored identifier. If they match, then proceed to step 315. The description of the locally stored identifier on the reading and writing device side is the same as in the previous embodiment and will not be repeated.

[0144] In one example, the read / write device compares or determines whether the second identifier carried in the reaccess message is consistent with the locally pre-stored first identifier (i.e., at least part of the permanent identifier or at least part of the temporary identifier) ​​and / or the locally pre-stored underlying identifier; if the second identifier carried in the reaccess message is consistent with the locally pre-stored first identifier or consistent with the locally pre-stored underlying identifier, the read / write device executes step 315.

[0145] This example is particularly applicable to situations where there is no restriction on which identifier the AIoT device side will use as the second identifier.

[0146] Specifically, the process of comparing or determining whether the second identifier carried in the re-access message is consistent with the first identifier pre-stored locally can be as follows: the reading and writing device determines whether the second identifier carried in the re-access message is the same as the first identifier of any AIoT device pre-stored locally by the reading and writing device; or, the reading and writing device determines whether the second identifier carried in the re-access message includes the first identifier of any AIoT device pre-stored locally by the reading and writing device.

[0147] The reading and writing device can compare or determine whether the second identifier carried in the re-access message is consistent with the underlying identifier pre-stored locally. This can be done by the reading and writing device determining whether the second identifier carried in the re-access message is the same as the underlying identifier of any AIoT device pre-stored locally by the reading and writing device.

[0148] It should be noted that the reading and writing device can perform the process of determining whether the second identifier carried in the re-access message is consistent with the first identifier stored locally, and the process of determining whether the second identifier carried in the re-access message is consistent with the underlying identifier stored locally, either sequentially or simultaneously.

[0149] For example, the read / write device first compares or determines whether the second identifier carried in the re-access message matches any of the locally pre-stored first identifiers. If the second identifier carried in the re-access message matches any of the locally pre-stored first identifiers, then the second identifier carried in the re-access message is determined to be correct. If the second identifier carried in the re-access message does not match any of the locally pre-stored first identifiers, then the read / write device compares or determines whether the second identifier carried in the re-access message matches any of the locally pre-stored underlying identifiers. If the second identifier carried in the re-access message matches one of the locally pre-stored underlying identifiers, then the second identifier carried in the re-access message is determined to be correct. The above is only an illustrative example. In actual processing, it is also possible to first compare or determine whether the second identifier carried in the re-access message matches the locally pre-stored underlying identifiers, and if they do not match, then compare or determine whether the second identifier carried in the re-access message matches the locally pre-stored first identifiers. This will not be elaborated further here.

[0150] For another example, the read / write device simultaneously compares or determines whether the second identifier carried in the re-access message is consistent with any of the first identifiers pre-stored locally, and compares or determines whether the second identifier carried in the re-access message is consistent with any of the underlying identifiers pre-stored locally; as long as the second identifier carried in the re-access message is consistent with any of the underlying identifiers or any of the first identifiers pre-stored locally, then the second identifier carried in the re-access message is determined to be correct.

[0151] Additionally, it may include: if the second identifier carried in the re-access message is inconsistent with the first identifier stored locally, and the second identifier carried in the re-access message is inconsistent with the underlying identifier stored locally, the reading / writing device may terminate the processing or return to step 311.

[0152] In another example, the AIoT device can pre-configure rules or policies related to the identifiers it provides. The AIoT device then needs to determine which identifier to use as the second identifier based on these rules or policies. In this example, the read / write device can also pre-configure rules that match or correspond to the AIoT device.

[0153] For example, the read / write device can determine whether to compare or match the second identifier carried in the re-access message with the pre-stored first identifier based on the relevant rules or strategies for identifier matching.

[0154] Specifically, the read / write device compares or determines whether the second identifier carried in the re-access message matches the locally pre-stored first identifier (i.e., at least a part of the permanent identifier or at least a part of the temporary identifier); if the second identifier carried in the re-access message matches the locally pre-stored first identifier, the read / write device executes step 315. Alternatively, if the second identifier carried in the re-access message does not match the locally pre-stored first identifier, the read / write device may terminate the process or return to step 311.

[0155] For example, the read / write device can determine whether to compare or match the second identifier carried in the re-access message with the pre-stored underlying identifier based on the relevant rules or strategies for identifier matching.

[0156] Specifically, the read / write device compares or determines whether the second identifier carried in the re-access message is consistent with the locally pre-stored underlying identifier; if the second identifier carried in the re-access message is consistent with the locally pre-stored underlying identifier, the read / write device executes step 315. Alternatively, if the second identifier carried in the re-access message is inconsistent with the locally pre-stored underlying identifier, the read / write device may end the processing or return to execute step 311.

[0157] Step 315: The read / write device sends a second response message. Specifically, the read / write device sends a second response message to the AIoT functional entity. Correspondingly, the AIoT functional entity receives the second response message from the read / write device. This second response message carries a first identifier or an underlying identifier.

[0158] Whether the read / write device carries the first identifier or the underlying identifier in the second response message can be determined by the read / write device itself, or by the read / write device based on a pre-configured local policy and / or related protocols.

[0159] For example, the read / write device may determine, based on a pre-configured local policy and / or related protocol, that it carries the first identifier, which was pre-stored in step 304 and sent by the AIoT functional entity, in the second response message.

[0160] For example, the read / write device may determine, based on a pre-configured local policy and / or related protocol, its pre-stored underlying identifier and carry it in the second response message.

[0161] Optionally, the second request message can be an inventory request message; correspondingly, the second response message can be an inventory report or an inventory report message.

[0162] Optionally, the second request message is a command request message; correspondingly, the second response message is a command report or a command report message.

[0163] In this case, if the reconnection message carries command response data, then the second response message carries command response data in addition to the first identifier or underlying identifier of the AIoT device.

[0164] It should also be noted that, in addition to the content or parameters mentioned above, the second response message may also carry other content or parameters specified in the relevant protocol. For example, the second response message may also carry a Correlation ID and / or the identifier of the reading / writing device, etc.

[0165] Step 316: The AIoT functional entity sends a response message to the AF corresponding to the business request.

[0166] Step 316 can be an optional step.

[0167] In one example, if step 301 is not executed, but step 302 is triggered by the AIoT functional entity based on local policies, rules or protocols, then step 316 can be omitted.

[0168] In one example, if step 301 is executed, step 316 can then be executed. The content carried by the response message corresponding to the business request may only include the content of the second response message; or, the content carried by the response message corresponding to the business request may include the content of the second response message, and may also include other content or parameters, which is not limited here.

[0169] In one scenario, the business request sent by AF to the AIoT functional entity in step 301 is used for inventory (i.e., inventory request message). Correspondingly, the response message to the business request in step 316 can be an inventory notification.

[0170] In another scenario, the business request sent by AF to the AIoT functional entity in step 301 is a command (i.e., a command request message), and correspondingly, the response message in step 316 corresponding to the business request can be a command notification.

[0171] The solution provided in the above embodiments allows the reader / writer to trigger the AIoT device to re-access when the response message from the AIoT device is abnormal. The AIoT device then retransmits its identifier during the re-access process. This allows the reader / writer to trigger the AIoT device to retransmit its identifier for re-access even when the AIoT device is paged but the response message received by the reader / writer is abnormal. This avoids the problem of reduced paging efficiency caused by the network side considering the AIoT device a paging failure and re-paged the AIoT device when the response message is abnormal.

[0172] In some possible implementations, referring to Figure 4, one implementation flow of the communication method provided in this application is described:

[0173] The related processing in step 401 is the same as in step 301, and will not be repeated here.

[0174] Step 402: The AIoT functional entity sends a first identifier of the AIoT device and parameters for generating a temporary identifier; correspondingly, the read / write device receives the first identifier from the AIoT functional entity, and the reading / write device's processing further includes receiving the parameters for generating the temporary identifier from the AIoT functional entity. Specifically, the AIoT functional entity sends a second request message to the read / write device; correspondingly, the read / write device receives the second request message, wherein the second request message carries the first identifier and parameters for generating the temporary identifier, and the first identifier includes at least a portion of the temporary identifier.

[0175] Optionally, the first identifier may include temporary identifiers, that is, the first identifier is all of the temporary identifiers.

[0176] Optionally, the first identifier may include a portion of a temporary identifier (or a partial temporary identifier). This approach can reduce the signaling overhead of subsequent paging; it can be applied to paging individual AIoT devices or to paging groups of devices.

[0177] The difference between this embodiment and the previous embodiment is that the first identifier is part or all of a temporary identifier, which is calculated by the AIoT functional entity, and the AIoT functional entity also issues parameters for generating the temporary identifier.

[0178] The specific processing of calculating the temporary identifier on the AIoT functional entity side can be as follows: calculating the temporary identifier based on the parameters used to generate the temporary identifier. The parameters used to generate the temporary identifier include at least one of the following: a random number, a count value, etc.

[0179] The step of calculating the temporary identifier based on the parameters used to generate the temporary identifier includes: calculating the temporary identifier based on the parameters used to generate the temporary identifier and at least one of the following: the permanent identifier of the AIoT device, and the underlying identifier of the AIoT device.

[0180] For example, AIoT functional entities can use pre-configured algorithms to calculate a temporary identifier from the permanent identifier of the AIoT device and the parameters used to generate the temporary identifier.

[0181] For example, AIoT functional entities can use pre-configured algorithms to calculate temporary identifiers based on the underlying identifiers of AIoT devices and the parameters used to generate temporary identifiers.

[0182] For example, AIoT functional entities can use pre-configured algorithms to calculate temporary identifiers from the underlying identifier, permanent identifier, and parameters used to generate temporary identifiers of AIoT devices.

[0183] In the process of calculating the temporary identifier, other parameters can also be used, such as the key shared by the AIoT device and the AIoT functional entity; for example, the AIoT functional entity uses a pre-configured algorithm to calculate the temporary identifier from the permanent identifier of the AIoT device, the key, and the parameters used to generate the temporary identifier.

[0184] The pre-configured algorithm can be pre-configured on the AIoT functional entity and AIoT device side. For example, the pre-configured algorithm may include at least one of the following: hash function, encryption algorithm, integrity guarantee algorithm, KDF (Key Derivation Function), XOR calculation, direct connection calculation, HMAC (Hash-based Message Authentication Code), etc. These are all illustrative examples, and this embodiment does not limit or exhaustively list all possible algorithms for the pre-configured algorithm.

[0185] For example, the calculation of a temporary identifier can be represented as follows: Temp ID = f(Permanent ID / EPC, parameter), where Temp ID represents the temporary identifier, Permanent ID represents the permanent identifier, EPC represents the underlying identifier, " / " means "or", "parameter" is the parameter used to generate the temporary identifier, and f() is a pre-configured algorithm used to calculate the temporary identifier.

[0186] It should be noted that the above are all illustrative examples. In actual processing, other possible parameters may be used to calculate the temporary identifier, which are not limited or exhaustively listed here.

[0187] The second request message can be an inventory request message or a command request message. The specific business process in which the second request message is located, its message type, and any other content or parameters it may carry are similar to those in step 302 of the aforementioned embodiments, and therefore will not be repeated.

[0188] In one approach, the AIoT functional entity determines, based on the business request, that only inventory counting, inventory counting and commands, or only command processing are required, and triggers or determines to execute step 402. In another approach, step 401 may not be executed; instead, the AIoT functional entity triggers execution of step 402 based on local policies, rules, or protocols. The descriptions of these two possible methods for triggering execution of step 402 are the same as those for the two methods for triggering execution of step 302 in the aforementioned embodiments, and therefore will not be repeated.

[0189] Step 403 is the same as step 303, and will not be repeated.

[0190] Step 404: The reading and writing device pre-stores the first identifier (i.e., at least a portion of the temporary identifier). Specifically, the reading and writing device reads the first identifier (i.e., at least a portion of the temporary identifier) ​​of the AIoT device and the parameters used to generate the temporary identifier from the second request message and pre-stores or saves them locally.

[0191] Step 405: The read / write device sends a first request message to the AIoT device, and the AIoT device receives the first request message. The first request message carries the first identifier and also carries parameters for generating a temporary identifier. This first request message may be carried by a paging message.

[0192] Step 406: The AIoT device calculates a temporary identifier based on the parameters used to generate the temporary identifier.

[0193] The step of calculating the temporary identifier based on the parameters used to generate the temporary identifier includes: calculating the temporary identifier based on the parameters used to generate the temporary identifier and at least one of the following: the permanent identifier of the AIoT device, and the underlying identifier of the AIoT device.

[0194] The processing of temporary identifiers for this AIoT device should be the same as that for AIoT functional entities, and will not be repeated here.

[0195] The processing after the AIoT device calculates a temporary identifier includes: if it verifies or determines that the first identifier matches the temporary identifier it has calculated, then it is determined that paging itself, i.e., the AIoT device has been successfully paged, and then step 407 is executed. Alternatively, if the AIoT device verifies or determines that the first identifier does not match the temporary identifier it has calculated, then it is determined that it is not paging itself, and subsequent processing is not required.

[0196] In one scenario, the first identifier includes all of the temporary identifiers.

[0197] If the first identifier is the same as the temporary identifier calculated by itself, the AIoT device verifies or determines that the first identifier matches the temporary identifier calculated by itself; and / or, if the first identifier is different from the temporary identifier calculated by itself, the AIoT device verifies or determines that the first identifier does not match the temporary identifier calculated by itself.

[0198] In another scenario, the first identifier may include a portion of the temporary identifier.

[0199] If the temporary identifier calculated by the AIoT device includes the first identifier, the AIoT device verifies or determines that the first identifier matches the temporary identifier calculated by the AIoT device; and / or, if the temporary identifier calculated by the AIoT device does not include the first identifier, the AIoT device verifies or determines that the first identifier does not match the temporary identifier calculated by the AIoT device.

[0200] Steps 407 to 408 are the same as those described in steps 306 to 307 of the previous embodiment, and will not be repeated.

[0201] Step 409: The AIoT device sends a first response message, wherein the first response message carries the second identifier. Specifically, the AIoT device sends a first response message corresponding to the first request message to the read / write device; correspondingly, the read / write device receives the first response message from the AIoT device. This first response message is carried by a paging response message.

[0202] For example, if the AIoT device performs a four-step random access process, then after performing steps 407 to 408, step 409 is performed. The specific way the paging response message is carried is the same as in the previous embodiment, and will not be described again.

[0203] For example, if the AIoT device performs a two-step random access process, steps 407 and 408 can be skipped, and step 409 can be executed directly. The paging response message in step 409 can be transmitted as the payload of msgA in the two-step random access process, or the paging response message can be carried by msgA. The specific method of carrying the paging response message is the same as in the previous embodiments and will not be described again.

[0204] Here, when the AIoT device sends the first response message normally, the first response message should carry the second identifier of the AIoT device.

[0205] The second identifier includes one of the following: at least a portion of a temporary identifier, or an underlying identifier. The second identifier of an AIoT device can refer to the correct identification information of the AIoT device. Preferably, the second identifier is at least a portion of a temporary identifier; alternatively, the second identifier is an underlying identifier.

[0206] In one approach, the second identifier is the same as the first identifier received by the AIoT device, or the second identifier contains the first identifier, or the second identifier is an underlying identifier. In this case, there is no restriction on which identifier the AIoT device will use as the second identifier; the AIoT device itself can randomly select which identifier to use as the second identifier.

[0207] For example, an AIoT device can use an identifier that is the same as the first identifier as the second identifier. For instance, the first identifier could be any temporary identifier, and the second identifier could also be any temporary identifier that is the same as the first identifier. Here, we do not limit or exhaust all possible cases.

[0208] For example, when the first identifier is a part of a temporary identifier, the AIoT device can use an identifier containing the first identifier as the second identifier, or use the first identifier as the second identifier. For instance, when the first identifier is a part of a temporary identifier, the second identifier can be a part of a temporary identifier that is the same as the first identifier, or the second identifier can be all of the temporary identifiers. Here, we do not limit or exhaust all possible cases.

[0209] For example, regardless of the first identifier, an AIoT device can use the underlying identifier as the second identifier.

[0210] Alternatively, the AIoT device can pre-configure rules or policies related to the identifiers it feeds back. The AIoT device then needs to determine which identifier to use as the second identifier based on these rules or policies. For example, the AIoT device can determine whether to use an identifier that is the same as the first identifier, an identifier that contains the first identifier, or an underlying identifier as the second identifier.

[0211] The solutions provided in this application address the same abnormal or erroneous situations as those described in the foregoing embodiments, and will not be repeated here.

[0212] Step 410 is the same as step 309, and will not be described again.

[0213] After completing step 410, the processing of the read / write device further includes at least one of the following: determining that the first response message is abnormal when it does not contain the first identifier of the AIoT device; determining that the first response message is abnormal when it does not contain the underlying identifier of the AIoT device. Additionally, the processing of the read / write device further includes: determining that the first response message is normal when it contains either the first identifier or the underlying identifier.

[0214] As shown in Figure 4, the read / write device can execute step 411, whereby the read / write device determines whether the received first response message contains a locally stored identifier. If it does not contain the identifier, the first response message is determined to be abnormal, and then step 412 is executed.

[0215] This embodiment proposes a handling mechanism for the following error: the identification information of the AIoT device received by the reading and writing device is inconsistent with the identification pre-stored on the reading and writing device side. The reading and writing device knows that it will only send a first response message when the AIoT device is successfully paged, and correspondingly, it will only receive the first response message sent by the AIoT device. Therefore, if the reading and writing device determines that the first response message of the AIoT device is incorrect or abnormal, it can determine that the first response message sent by the AIoT device is erroneous or abnormal, and the reading and writing device decides to execute step 412.

[0216] Additionally, it may include: if the first response message contains a locally stored identifier, the read / write device determines that the first response message is normal, and the read / write device can execute step 417.

[0217] The identifiers pre-stored locally by the read / write device include: the identifier information of the AIoT device pre-stored by the read / write device; in addition, the identifiers pre-stored locally by the read / write device may also include the identifier information of one or more other AIoT devices pre-stored by the read / write device. Taking the identifier information of the AIoT device pre-stored by the read / write device as an example, the AIoT device identifier information pre-stored by the read / write device includes: the first identifier of the AIoT device pre-stored by the read / write device in step 404 (i.e., at least a part of the temporary identifier), and / or the underlying identifier of the AIoT device pre-stored locally by the read / write device.

[0218] The specific processing by which the read / write device determines whether the received first response message contains a locally stored identifier is similar to that in the previous embodiments. The only difference is that in this embodiment, the first identifier is part or all of a temporary identifier, so it will not be described again.

[0219] Steps 412 to 413 are the same as steps 311 to 312 in the previous embodiments, and will not be described again.

[0220] Step 414: The AIoT device recalculates the temporary identifier. The process for recalculating the temporary identifier is the same as the process for calculating the temporary identifier described above, and therefore will not be repeated.

[0221] Step 414 can be an optional step.

[0222] In one example, step 414 can be performed.

[0223] In this example, after receiving the first request message, the AIoT device can save the parameters used to generate a temporary identifier from the first request message, and can set a timer to delete the parameters used to generate the temporary identifier when the timer's timeout period is reached. The start time of the timer can be the moment the first request message is received, and the timeout period of the timer can be configured according to the actual situation, such as 10 minutes, 1 hour, 1 minute, or longer or shorter. There is no limitation here, as long as step 413 can be completed within the timeout period, it is within the protection scope of this embodiment.

[0224] Alternatively, in this example, the AIoT device could delete the parameters used to generate the temporary identifier after sending the first response message, upon the next paging message or command request message received.

[0225] In another example, step 414 can be omitted. In this example, the AIoT device can delete the parameter used to generate the temporary identifier after the first calculation of the temporary identifier, and only save the temporary identifier locally; after completing step 413, step 415 can be executed directly.

[0226] Step 415: The AIoT device sends a re-access message, which carries the AIoT device's second identifier (i.e., correct identification information). Specifically, the AIoT device sends the re-access message to the read / write device; correspondingly, the read / write device receives the re-access message from the AIoT device.

[0227] Preferably, the second identifier is at least a part of the temporary identifier; optionally, the second identifier is the underlying identifier. The descriptions of the second identifier, including the specific type and content of the second identifier determined by the AIoT device, are the same as those in step 409 above and will not be repeated.

[0228] The processing after the read / write device receives the re-access message includes: when the second identifier matches the first identifier of the AIoT device or the underlying identifier of the AIoT device, the read / write device sends a second response message, wherein the second response message carries the first identifier or the underlying identifier. The specific processing performed by the read / write device may include the following steps 416-417:

[0229] Step 416: The reading and writing device compares the second identifier carried in the received re-access message with the identifier pre-stored locally by the reading and writing device. If they match, then proceed to step 417. The description of the identifier pre-stored locally by the reading and writing device is the same as in the previous embodiment and will not be repeated.

[0230] The specific processing of this step is similar to that of step 314, except that, preferably in this embodiment, the second identifier can be at least a part of a temporary identifier; correspondingly, preferably, as shown in FIG4, step 416 is for the reading and writing device to compare the received second identifier of the AIoT device with at least a part of the pre-stored temporary identifier, and if they match, then step 417 is executed. Optionally, the reading and writing device can compare the received second identifier of the AIoT device with the pre-stored underlying identifier, and if they match, then step 417 is executed.

[0231] The explanations regarding whether the second identifier carried in the received re-access message is consistent with the identifier pre-stored locally by the reading and writing device in this step are similar to those in step 314, and therefore will not be repeated.

[0232] Step 417: The read / write device sends a second response message. Specifically, the read / write device sends a second response message to the AIoT functional entity. Correspondingly, the AIoT functional entity receives the second response message from the read / write device.

[0233] This step is similar to step 315, except that in this step, the second response message preferably carries the first identifier (i.e., at least a portion of the temporary identifier shown in Figure 4). Optionally, the second response message may carry the underlying identifier. Other related descriptions of this step are the same as those of step 315 in the aforementioned embodiments, and therefore will not be repeated.

[0234] The relevant explanations for steps 418 and 316 are the same, and will not be repeated here.

[0235] The solution provided in the above embodiments allows the reader / writer to trigger the AIoT device to re-access when the response message from the AIoT device is abnormal. The AIoT device then retransmits its identifier during the re-access process. This allows the reader / writer to trigger the AIoT device to retransmit its identifier for re-access even when the AIoT device is paged but the response message received by the reader / writer is abnormal. This avoids the problem of reduced paging efficiency caused by the network side considering the AIoT device a paging failure and re-paged the AIoT device when the response message is abnormal.

[0236] Furthermore, in scenarios where the first identifier is at least a part of a temporary identifier, parameters for generating the temporary identifier can be sent to the AIoT device via a request message; thus, when the reading / writing device triggers the AIoT device to re-access, the AIoT device can recalculate the temporary identifier. This avoids paging failures caused by incorrect or failed generation of the temporary identifier.

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

[0238] The first communication unit 501 is configured to send a first request message to an AIoT device, wherein the first request message carries a first identifier of the AIoT device; receive a first response message from the AIoT device; when the first response message is abnormal, send indication information to the AIoT device, wherein the indication information is used to trigger the AIoT device to re-access; and receive a re-access message from the AIoT device, wherein the re-access message carries a second identifier of the AIoT device.

[0239] As shown in Figure 5, the read / write device also includes:

[0240] The first processing unit 502 is configured to perform at least one of the following: when the first response message does not contain the first identifier, determine that the first response message is abnormal; when the first response message does not contain the underlying identifier of the AIoT device, determine that the first response message is abnormal.

[0241] The underlying identifier is pre-stored by the read / write device.

[0242] The first communication unit is configured to receive the first identifier from the AIoT functional entity.

[0243] The first identifier includes one of the following: at least a portion of a permanent identifier, or at least a portion of a temporary identifier.

[0244] The first communication unit is configured to receive parameters from the AIoT functional entity for generating a temporary identifier.

[0245] The first request message also carries the parameters used to generate the temporary identifier.

[0246] The first communication unit is configured to send a second response message when the second identifier matches the first identifier of the AIoT device or the underlying identifier of the AIoT device, wherein the second response message carries the first identifier or the underlying identifier.

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

[0248] The second communication unit 601 is used to receive indication information, wherein the indication information is used to trigger the AIoT device to re-access; and to send a re-access message, wherein the re-access message carries the second identifier of the AIoT device.

[0249] The second communication unit is configured to receive a first request message, wherein the first request message carries a first identifier of the AIoT device.

[0250] The first identifier includes one of the following: at least a portion of a permanent identifier, or at least a portion of a temporary identifier.

[0251] The first request message also carries parameters for generating a temporary identifier.

[0252] As shown in Figure 6, AIoT devices also include:

[0253] The second processing unit 602 is used to calculate the temporary identifier based on the parameters used to generate the temporary identifier.

[0254] The second processing unit is configured to calculate the temporary identifier based on the parameters used to generate the temporary identifier and at least one of the following: the permanent identifier of the AIoT device, and the underlying identifier of the AIoT device.

[0255] The second communication unit is configured to send a first response message, wherein the first response message carries the second identifier.

[0256] The second identifier includes one of the following: at least a portion of a permanent identifier, at least a portion of a temporary identifier, or an underlying identifier.

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

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

[0259] Figure 7 is a schematic structural diagram of a communication device 700 according to an embodiment of this application. The communication device 700 includes a processor 710, which can call and run computer programs from a memory to enable the communication device 700 to implement the methods in the embodiments of this application. In one possible implementation, the communication device 700 may further include a memory 720. The processor 710 can call and run computer programs from the memory 720 to enable the communication device 700 to implement the methods in the embodiments of this application. The memory 720 may be a separate device independent of the processor 710, or it may be integrated into the processor 710. In one possible implementation, the communication device 700 may further include a transceiver 730, which the processor 710 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 730 may include a transmitter and a receiver. The transceiver 730 may further include antennas, and the number of antennas may be one or more.

[0260] In one possible implementation, the communication device 700 may be an AIoT device or a read / write device in the embodiments of this application, and the communication device 700 may implement the corresponding processes implemented by the AIoT device 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.

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

[0262] In one possible implementation, the chip can be applied to the AIoT device or read / write device in the embodiments of this application, and the chip can implement the corresponding processes implemented by the AIoT device 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 may 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.

[0263] This application also provides a communication system. The communication system includes an AIoT device 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, and the read / write device is used to implement the corresponding functions implemented by the read / write device in the above-described method.

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

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

1. A communication method executed by a read / write device, comprising: Send a first request message to the AIoT device, wherein the first request message carries a first identifier of the AIoT device; Receive a first response message from the AIoT device; When the first response message is abnormal, an indication message is sent to the AIoT device, wherein the indication message is used to trigger the AIoT device to reconnect; Receive a re-access message from the AIoT device, wherein the re-access message carries a second identifier of the AIoT device.

2. The method of claim 1, further comprising at least one of the following: When the first response message does not contain the first identifier, the first response message is determined to be abnormal; If the first response message does not contain the underlying identifier of the AIoT device, the first response message is determined to be abnormal.

3. The method of claim 2, wherein, The underlying identifier is pre-stored by the read / write device.

4. The method according to claim 1, further comprising: Receive the first identifier from the AIoT functional entity.

5. The method according to any one of claims 1 to 4, wherein, The first identifier includes one of the following: at least a portion of a permanent identifier, or at least a portion of a temporary identifier.

6. The method according to claim 5, further comprising: Receive parameters from the AIoT functional entity for generating a temporary identifier.

7. The method of claim 6, wherein, The first request message also carries the parameters used to generate the temporary identifier.

8. The method according to any one of claims 1-7, further comprising: When the second identifier matches the first identifier of the AIoT device or the underlying identifier of the AIoT device, a second response message is sent, wherein the second response message carries the first identifier or the underlying identifier.

9. A communication method performed by an AIoT device, comprising: Receive indication information, wherein the indication information is used to trigger the AIoT device to reconnect; Send a re-access message, wherein the re-access message carries a second identifier of the AIoT device.

10. The method of claim 9, further comprising: Receive a first request message, wherein the first request message carries a first identifier of the AIoT device.

11. The method of claim 10, wherein, The first identifier includes one of the following: at least a portion of a permanent identifier, or at least a portion of a temporary identifier.

12. The method of claim 11, wherein, The first request message also carries parameters for generating a temporary identifier.

13. The method of claim 12, further comprising: The temporary identifier is calculated based on the parameters used to generate the temporary identifier.

14. The method of claim 13, wherein, The step of calculating the temporary identifier based on the parameters used to generate the temporary identifier includes: The temporary identifier is calculated based on the parameters used to generate the temporary identifier and at least one of the following: the permanent identifier of the AIoT device, and the underlying identifier of the AIoT device.

15. The method according to any one of claims 10-14, further comprising: Send a first response message, wherein the first response message carries the second identifier.

16. The method of any one of claims 9-15, wherein, The second identifier includes one of the following: at least a portion of a permanent identifier, at least a portion of a temporary identifier, or an underlying identifier.

17. A read / write device, comprising: A first communication unit is configured to send a first request message to an AIoT device, wherein the first request message carries a first identifier of the AIoT device; receive a first response message from the AIoT device; when the first response message is abnormal, send indication information to the AIoT device, wherein the indication information is used to trigger the AIoT device to re-access; and receive a re-access message from the AIoT device, wherein the re-access message carries a second identifier of the AIoT device.

18. An AIoT device, comprising: The second communication unit is used to receive indication information, wherein the indication information is used to trigger the AIoT device to re-access; and to send a re-access message, wherein the re-access message carries the second identifier of the AIoT device.

19. 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 1 to 8.

20. An AIoT 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 AIoT device to perform the method as described in any one of claims 9 to 16.

21. A chip comprising: A processor for retrieving and running a computer program from memory, causing a device on which the chip is mounted to perform the method as claimed in any one of claims 1 to 8 or 9 to 16.

22. A computer-readable storage medium for storing a computer program that, when run by a device, causes the device to perform the method as claimed in any one of claims 1 to 8 or 9 to 16.

23. A computer program product comprising computer program instructions that cause a computer to perform the method as claimed in any one of claims 1 to 8 or 9 to 16.

24. A computer program that causes a computer to perform the method as claimed in any one of claims 1 to 8 or 9 to 16.

Images